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: 25+ 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
2004-06-10 19:14 ` viro
2004-06-10 19:32 ` Greg KH
2004-06-10 19:38 ` viro
2004-06-10 20:28 ` Sam Ravnborg
2004-06-10 20:48 ` Randy.Dunlap
2004-06-11 17:21 ` Jean Delvare
2004-06-11 17:59 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox