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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 10 May 2020 04:01:26 +0100
From:   Al Viro <>
To:     Linus Torvalds <>
Cc:     Tetsuo Handa <>,
        Linux Kernel Mailing List <>,
        linux-fsdevel <>
Subject: Re: [PATCH 05/20] tomoyo_write_control(): get rid of pointless

On Sat, May 09, 2020 at 05:57:56PM -0700, Linus Torvalds wrote:
> On Sat, May 9, 2020 at 5:51 PM Tetsuo Handa
> <> 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

* 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.

Powered by blists - more mailing lists