From: Linus Torvalds <email@example.com>
Subject: Re: Finding user/kernel pointer bugs [no html]
Date: Thu, 10 Jun 2004 15:07:33 GMT
On Thu, 10 Jun 2004, Timothy Miller wrote:
> Are user pointers actual pointers?
Yes. They have to be. We could make them "unsigned long" or something, but
the fact is, they do have all the pointer attributes: they are pointers to
structures, they have _meaning_.
> That's much too tempting to dereference.
Absolutely. Which is why sparse extends the C type system so that you can
be a pointer yet _also_ not be something you can directly dereference.
int __user * a;
*a = 0;
test.c:6:3: warning: dereference of noderef expression
test.c:7:10: warning: dereference of noderef expression
> If you really want to force user space accesses to follow certain rules,
> make them longs or structs (or at least void *) (depending on
> architecture) so that only the proper user-space-access functions can
> interpret them.
... and this would be a total disaster.
Think about it. The user pointer isn't just a "value". It has a type it
points to. We want to do
if (get_user(len, &uiov32->iov_len) ||
and yes, the above is a real example. In fact, if you grep for "get_user"
in linux/*/*.c _most_ of the uses seem to be of this type.
In other words: user pointers _are_ pointers. You have to be able to
access member names through them etc. It's just that you can't dereference
them directly - but they definitely have all the other attributes of a
> Now, if this "handle" corresponds directly to a user space pointer,
> someone might cast it and dereference it, but that would be easy to
> detect, and such patches would be easy to reject.
> Bad idea?
Yes. Handles are a bad idea. They make the code unreadable and totally
Realize that if you use just one type (the "handle") for user pointers,
you also totally lose all C type-checking. You can't see the difference
between a "pointer to an old-style 'struct stat'" and a "pointer to a
new-style 'struct stat64'". So then you'd have to add your own crud to do
type verifications (add magic words to the handle that describe the type
It's a nightmare.
You want strict _static_ type analysis. Static type analysis has zero
run-time costs, and means that you get the "right" answer at compile-time.
And that's exactly what sparse is all about. Static type analysis.