linux-kernel - Re: [PATCH 03/11] fs: add new read_uptr and write

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:   Mon, 29 Jun 2020 17:29:12 +0200
From:   Christoph Hellwig <hch@....de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Laight <David.Laight@...lab.com>,
        Christoph Hellwig <hch@....de>,
        Al Viro <viro@...iv.linux.org.uk>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 03/11] fs: add new read_uptr and write_uptr file
 operations

On Sat, Jun 27, 2020 at 09:33:03AM -0700, Linus Torvalds wrote:
> I thought there was just one very specific case of "oh, in certain
> cases of setsockopt we don't know what size this address is and optlen
> is ignored", so we have to just pass the pointer down to the protocol,
> which is the point that knows how much of an address it wants..

The setsock issue is a little more complicated.  Let me try to summarize
it:

 - setsock takes a (user) pointer and len
 - unfortunately while the designed of the BSD socket API designed the
   len to be correct some protocol implementations have been sloppy
   and just use a hardcoded len for the value plus some other funnies
 - unfortunately there is some BPF magic that can attach to a socket
   and be run, and that (and only that in the latest kernel) can cause
   a setsockopt to take a kernel buffer.  One that was copied from
   userspace earlier and had the BPF program run on it.
 - unfortunately we have about 90 ->setsockopt instances, and the BPF
   hook is not specific to one particular of them.  In fact the
   BPF program can run for options that don't even exist, and based on
   my previous dicussion Facebook has setups that rely on that.

> Was that a misunderstanding on my part?
> 
> Because if there are tons and tons of places that want this "either
> kernel or user" then we could still have a helper function for it, but
> it means that the whole "limit the cases" advantage to some degree
> goes away.

But except for setsockopt we don't really have anything like that left.
There is some alpha arch code that would need to be duplicated for
user vs kernel pointers, but I suspect it will get cleaner by that,
and the messy s390 crypto driver whіch will be a bit of work, but all
internal to that driver.

So based on that I'd rather get away without our flag and tag the
kernel pointer case in setsockopt explicitly.