linux-kernel - Re: [git pull] uaccess-related bits of vfs.git

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:   Sat, 13 May 2017 09:46:59 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     Adam Borowski <kilobyte@...band.pl>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 8:05 AM, Adam Borowski <kilobyte@...band.pl> wrote:
> On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote:
>> On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote:
>> > But the *first* thing I'd like to do would be to just get rid of
>> > __get_user/__put_user as a thing. It really does generate nasty code,
>> > and we might as well just make it do that function call.
>>
>> But IMO the first step is not to convert __get_user()/__put_user() to
>> aliases of get_user()/put_user() - it's to get rid of their infestations
>> outside of arch/*.  They are concentrated in relatively few places, so
>> we can deal with those individually and then just fucking ban their use
>> outside of arch/*.  That's easy enough to watch for - simple git grep will do,
>> so anything creeping back will be immediately spotted.
>
> As someone from the peanuts gallery, I took a look for __put_user() in my
> usual haunt, drivers/tty/vt/
>
> * use 1: con_[gs]et_trans_*():
>   Copies a linear array of 256 bytes/shorts, one by one.
>   The obvious patch has 9 insertions(+), 22 deletions(-).
>
> * use 2: con_[gs]et_unimap():
>   Ditto, up to 65535*2 shorts, also in a nice linear array.
>
> * use 3: tioclinux():
>   Does a __put into a place that was checked only for read.  This got me
>   frightened as it initially looked like something that can allow an user to
>   write where they shouldn't.  Fortunately, it turns out the first argument
>   to access_ok() is ignored on every single architecture -- why does it even
>   exist then?  I imagined it's there for some odd arch that allows writes
>   when in privileged mode, but unlike what the docs say, VERIFY_WRITE is
>   exactly same as VERIFY_READ.

The original i386 (no longer supported) ignored the write-protect bit
when in supervisor mode.

--
Brian Gerst