lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 6 Oct 2015 14:29:39 +0100
From:	Linus Torvalds <>
To:	Ingo Molnar <>
Cc:	"H. Peter Anvin" <>,
	Dave Hansen <>,
	"Theodore Ts'o" <>,
	Andrew Morton <>,
	"" <>,
	Linux Kernel Mailing List <>
Subject: Re: [REGRESSION] 998ef75ddb and aio-dio-invalidate-failure w/ data=journal

On Tue, Oct 6, 2015 at 10:27 AM, Ingo Molnar <> wrote:
>> We really should try get rid of _all_ uses of the "__" versions unless they are
>> very locally and obviously checked with access_ok(). We've had way too many
>> cases where people thought they were clever, and weren't really.
> That's a good idea.
> The logistics worries me a bit: it looks like a major undertaking, considering the
> widespread use of these APIs in 1400+ call sites:

Well, quite frankly, I think I'd be ok with just a mass conversion of
the "__" functions to non-underscore ones.

>From past experience, I don't think we have anything that really
cares. The one exception is probably the signal stack handling,
because it really uses multiple individual accesses, and so it is much
more noticeable.

And there should be *no* meaningful difference between the underscore
version and the non-underscore one, unless somebody does something
really odd and questionable (ie depends on a kernel pointer - which
doesn't even work on all architectures!).

So I really think we could do a mass conversion of everything that
isn't under "arch/" (and obviously asm-generic/uaccess.h) in just one
single go.

I obviously wouldn't take that into 4.3, but I really don't think this
would merit splitting up into multiple patches either.

Then, one by one, we might convert back to __get/put_user() when we've
(a) added the SMAP/PAN infrastructure (b) verified that there's an
access_ok() _right_there_ and (c) actually verified that it's

I see drivers doing __get/put_user(), and it just makes me go "no".
Not only are drivers likely to get it wrong, I don't believe the extra
couple of cycles is going to matter compared to the cost of the
hardware access itself. And if the access_ok() isn't local and
obviously in the *only* place that can possibly lead to that code,
then the code shouldn't use the underscore versions.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists