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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZh9FJAXEfR4F+e30xwSigPdgzmErVxgpeMFjHwoScx1A@mail.gmail.com>
Date: Fri, 8 Dec 2023 14:42:28 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, 
	paul@...l-moore.com, linux-fsdevel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, keescook@...omium.org, 
	kernel-team@...a.com, sargun@...gun.me
Subject: Re: [PATCH bpf-next 1/8] bpf: fail BPF_TOKEN_CREATE if no delegation
 option was set on BPF FS

On Fri, Dec 8, 2023 at 1:49 PM Christian Brauner <brauner@...nel.org> wrote:
>
> On Thu, Dec 07, 2023 at 10:54:36AM -0800, Andrii Nakryiko wrote:
> > It's quite confusing in practice when it's possible to successfully
> > create a BPF token from BPF FS that didn't have any of delegate_xxx
> > mount options set up. While it's not wrong, it's actually more
> > meaningful to reject BPF_TOKEN_CREATE with specific error code (-ENOENT)
> > to let user-space know that no token delegation is setup up.
> >
> > So, instead of creating empty BPF token that will be always ignored
> > because it doesn't have any of the allow_xxx bits set, reject it with
> > -ENOENT. If we ever need empty BPF token to be possible, we can support
> > that with extra flag passed into BPF_TOKEN_CREATE.
> >
> > Signed-off-by: Andrii Nakryiko <andrii@...nel.org>
> > ---
>
> Might consider EOPNOTSUPP (or whatever the correct way of spelling this

I thought about that, but it felt wrong to return "unsupported" error
code, because BPF token is supported, it's just not setup/delegated on
that particular instance of BPF FS. So in that sense it felt like "BPF
token is not there" is more appropriate, which is why I went with
-ENOENT. And also I was worried that we might add -EOPNOTSUPP for some
unsupported combinations of flags or something, and then it will
become confusing to detect when some functionality is really not
supported, or if BPF token delegation isn't set on BPF FS. I hope that
makes sense and is not too contrived an argument.


> is). Otherwise,
> Acked-by: Christian Brauner <brauner@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ