[PATCH 0/3] Batched user access support
Linus Torvalds
torvalds at linux-foundation.org
Fri Dec 18 10:43:39 PST 2015
On Fri, Dec 18, 2015 at 10:33 AM, H. Peter Anvin <hpa at zytor.com> wrote:
> On 12/18/15 03:13, Will Deacon wrote:
>>
>> I'm pretty unimaginative when it comes to security exploits, but that
>> does sound worse than the current implementation from a security
>> perspective.
>>
>
> It is, but it is a tradeoff. It is way better than opening it up for
> the entire kernel.
So I wouldn't worry about the security part as long as we *only* do
this in core library routines, and never really expose it as some kind
of direct generic interface for random users.
It's one of the reasons I named those functions "unsafe". They really
aren't any more unsafe than the double underscore functions (which I
really dislike outside of core kernel code too), but it's just a bad
bad idea to use these in random drivers etc.
In fact, my first version of the patch restricted the code to only
non-module builds, but I ended up not posting that because the extra
#ifndef MODULE
...
#endif
just made it a bit uglier.
But I suspect we should do that in the long run. In fact, I would want
to do that for the __{get,put}_user() functions too, because there
really is no valid reason for drivers to use them.
So I would very strongly advocate that we only ever use these new
functions only for very core functions. Exactly things like
"strncpy_from_user()" and friends. I'd also possibly see it for things
like "cp_new_stat()", which right now copies to a temporary struicture
on the kernel stack, and then uses a "copy_to_user()" to copy the
temporary to user space. It's another very hot function on similar
stat-hot workloads, although in profiles it ends up not showing quite
as hot because the profile is split between the "set up on the kernel
stack" and the actual user copy.
Linus
More information about the linux-arm-kernel
mailing list