From: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Finding user/kernel pointer bugs [no html]
Date: 09 Jun 2004 22:20:51 -0700 [thread overview]
Message-ID: <1086844851.32052.411.camel@dooby.cs.berkeley.edu> (raw)
In-Reply-To: <20040610044903.GE12308@parcelfarce.linux.theplanet.co.uk>
On Wed, 2004-06-09 at 21:49, viro@parcelfarce.linux.theplanet.co.uk
wrote:
> On Wed, Jun 09, 2004 at 08:31:02PM -0700, Robert T. Johnson wrote:
> > Despite that, I found numerous bugs in seven drivers. Only one of these
> > drivers had any __user annotations, so sparse isn't able to provide any
> > meaningful results on these source files yet. Even worse, sparse missed
>
> But it does - they _all_ tripped warnings in sparse exactly due to the lack
> of __user.
Yeah, Linus pointed this stuff out. Sorry for my mistake.
> It's a different problem and a different class of bugs. Note that casts
> between userland and kernel pointers _do_ trip a warning, so we are really
I'm very glad to hear that. Casting between __user and __kernel is one
of my main concerns about sparse giving a false sense of security. Now
I can stop worrying.
> talking about either a non-user pointer in structure copied from userland
> (and for some reason not annotated, even though it is a part of userland
> ABI) *or* direct cast from integer type.
I just mentioned this scenario in my mail to Linus...
> 272 is interesting - it's in
> static void async_completed(struct urb *urb, struct pt_regs *regs)
> {
> struct async *as = (struct async *)urb->context;
> struct dev_state *ps = as->ps;
> struct siginfo sinfo;
>
> spin_lock(&ps->lock);
> list_move_tail(&as->asynclist, &ps->async_completed);
> spin_unlock(&ps->lock);
> if (as->signr) {
> sinfo.si_signo = as->signr;
> sinfo.si_errno = as->urb->status;
> sinfo.si_code = SI_ASYNCIO;
> sinfo.si_addr = (void *)as->userurb;
> send_sig_info(as->signr, &sinfo, as->task);
> }
> wake_up(&ps->wait);
> }
> and it brings two questions:
> a) shouldn't ->si_addr be a __user pointer (in all contexts I see
> it is one)
> b) WTF is usb doing messing with it directly?
> Note that drivers/usb/core/{devio,inode}.c are the only users of that animal
> outside of arch/*. Looks fishy...
Looks right. PATCH:
--- linux-2.6.7-rc3-full/include/asm-generic/siginfo.h.orig Wed Jun 9 22:09:49 2004
+++ linux-2.6.7-rc3-full/include/asm-generic/siginfo.h Wed Jun 9 22:09:52 2004
@@ -78,7 +78,7 @@ typedef struct siginfo {
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
struct {
- void *_addr; /* faulting insn/memory ref. */
+ void __user *_addr; /* faulting insn/memory ref. */
#ifdef __ARCH_SI_TRAPNO
int _trapno; /* TRAP # which caused the signal */
#endif
> > In my experiment above, I did
> > $ make menuconfig # Turn on every driver and feature I could
>
> make allmodconfig
Thanks!
> > > d) how fast $FOO is (it _is_ important, if you hope to get a decent
> > > code coverage, especially on non-x86 platforms).
> >
> > ~1 to 2 seconds per file.
>
> Erm... On what kind of box? ;-)
1GHz Pentium III.
> More interesting measurement is how much time out of the build is spend in
> gcc and how much in your code.
Rough estimate: 66% - 80% of time is cqual. I just did a quick
experiment that came out about 68%. So it takes about 3-4x as long as
it takes to just build.
Best,
Rob
next prev parent reply other threads:[~2004-06-10 5:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-10 3:31 Finding user/kernel pointer bugs [no html] Robert T. Johnson
2004-06-10 4:10 ` Linus Torvalds
2004-06-10 4:48 ` Robert T. Johnson
2004-06-10 14:46 ` Linus Torvalds
2004-06-10 16:57 ` viro
2004-06-10 15:07 ` Timothy Miller
2004-06-10 15:04 ` Linus Torvalds
2004-06-10 15:26 ` Timothy Miller
2004-06-10 4:49 ` viro
2004-06-10 5:20 ` Robert T. Johnson [this message]
2004-06-10 16:58 ` Greg KH
2004-06-10 17:27 ` David Brownell
2004-06-10 17:35 ` Greg KH
2004-06-10 17:54 ` Thomas Sailer
2004-06-10 18:34 ` Greg KH
2004-06-10 18:45 ` viro
2004-06-10 18:54 ` Greg KH
2004-06-10 19:10 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-06-10 19:14 ` viro
2005-05-19 6:25 ` viro
2004-06-10 19:32 ` Greg KH
2005-05-19 6:25 ` Greg KH
2004-06-10 19:38 ` viro
2005-05-19 6:25 ` viro
2004-06-10 20:28 ` Sam Ravnborg
2005-05-19 6:25 ` Sam Ravnborg
2004-06-10 20:48 ` Randy.Dunlap
2005-05-19 6:25 ` Randy.Dunlap
2004-06-11 17:21 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-06-11 17:59 ` Greg KH
2005-05-19 6:25 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1086844851.32052.411.camel@dooby.cs.berkeley.edu \
--to=rtjohnso@eecs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.