lists.openwall.net   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  linux-cve-announce  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:   Wed, 17 Jun 2020 11:19:59 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: rename probe_kernel_* and probe_user_*

On Wed, Jun 17, 2020 at 11:11 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I'm actually a bit surprised that we don't even get a warning for that
> horrible pattern that smells a bit like the gcc 'cast as lvalue'
> thing.

Oh, it's because I once again got confused by the naming.

"get_kernel_nofault()" doesn't have the "get_user()" semantics despite
being written like it. The arguments are in the reverse order, and the
pointer cast is on the address, not the target.

It's more obvious in the code, but not when grepping for things and
being used to the (much MUCH more common) get_user() semantics.

I really think get_kernel_nofault() should reverse the order of
arguments, because right now that "[PATCH 3/3] maccess: rename
probe_kernel_address to get_kernel_nofault" is really really
confusing.

You rename the function to look and act like get_user() (except for
kernel accesses, of course), but you leave it with an argument order
that is very much the reverse of what get_user() has.

So no. I won't be merging this series after all.

           Linus

Powered by blists - more mailing lists