linux-kernel - Re: [PATCH] files: rcu free files

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]

Message-ID: <20201210213624.GT3579531@ZenIV.linux.org.uk>
Date:   Thu, 10 Dec 2020 21:36:24 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Oleg Nesterov <oleg@...hat.com>, Jann Horn <jann@...jh.net>
Subject: Re: [PATCH] files: rcu free files_struct

On Thu, Dec 10, 2020 at 01:29:01PM -0600, Eric W. Biederman wrote:
> Al Viro <viro@...iv.linux.org.uk> writes:

> > What are the users of that thing and is there any chance to replace it
> > with something saner?  IOW, what *is* realistically called for each
> > struct file by the users of that iterator?
> 
> The bpf guys are no longer Cc'd and they can probably answer better than
> I.
> 
> In a previous conversation it was mentioned that task_iter was supposed
> to be a high performance interface for getting proc like data out of the
> kernel using bpf.
> 
> If so I think that handles the lifetime issues as bpf programs are
> supposed to be short-lived and can not pass references anywhere.
> 
> On the flip side it raises the question did the BPF guys just make the
> current layout of task_struct and struct file part of the linux kernel
> user space ABI?

An interesting question, that...  For the record: anybody coming to
complain about a removed/renamed/replaced with something else field
in struct file will be refered to Figure 1.

None of the VFS data structures has any layout stability warranties.
If BPF folks want access to something in that, they are welcome to come
and discuss the set of accessors; so far nothing of that sort has happened.

Direct access to any fields of any of those structures is subject to
being broken at zero notice.

IMO we need some notation for a structure being off-limits for BPF, tracing,
etc., along the lines of "don't access any field directly".