Re: [PATCH 05/20] tomoyo_write_control(): get rid of pointless access_ok()

From: Al Viro
Date: Sat May 09 2020 - 23:01:32 EST


On Sat, May 09, 2020 at 05:57:56PM -0700, Linus Torvalds wrote:
> On Sat, May 9, 2020 at 5:51 PM Tetsuo Handa
> <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > I think that this access_ok() check helps reducing partial writes (either
> > "whole amount was processed" or "not processed at all" unless -ENOMEM).
>
> No it doesn't.
>
> "access_ok()" only checks the range being a valid user address range.
>
> It doesn't actually help at all if the worry is "what if we take a
> page fault in the middle". Because it simply doesn't check those
> kinds of things.
>
> Now, if somebody passes actual invalid ranges (ie kernel addresses or
> other crazy stuff), they only have themselves to blame. The invalid
> range will be noticed when actually doing the user copy, and then
> you'll get EFAULT there. But there's no point in trying to figure that
> out early - it's only adding overhead, and it doesn't help any normal
> case.

It might be a good idea to add Documentation/what-access_ok-does_not ;-/
In addition to what you've mentioned,

* access_ok() does not fault anything in; never had.

* access_ok() does not verify that memory is readable/writable/there at all;
never had, except for genuine 80386 and (maybe) some of the shittier 486
clones.

* access_ok() does not protect you from the length being insanely large;
even on i386 it can pass with length being a bit under 3Gb. If you
count upon it to prevent kmalloc() complaints about insanely large
allocation (yes, I've seen that excuse used), you are wrong.

* on a bunch of architectures access_ok() never rejects anything, and
no, that's _not_ MMU-less ones. sparc64, for example. Or s390, or
parisc, etc.