linux-kernel - Re: [PATCH 0/2] two nits for path lookup

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: <20250417-sandplatz-hemmen-b357ce10b367@brauner>
Date: Thu, 17 Apr 2025 10:13:19 +0200
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: torvalds@...ux-foundation.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/2] two nits for path lookup

On Thu, Apr 17, 2025 at 12:16:24AM +0200, Mateusz Guzik wrote:
> since path looku is being looked at, two extra nits from me:
> 
> 1. some trivial jump avoidance in inode_permission()
> 
> 2. but more importantly avoiding a memory access which is most likely a
> cache miss when descending into devcgroup_inode_permission()

Serge did maintain this for a while. But honestly it is an absolute
legacy eyesore from the cgroup v1 days. Somehow it was decided that
device permission management is a good fit for cgroups. Idk, I have
ranted about this in other places at length. No use warming that back
up.

They later decided to reimplement device access management as a
dedicated bpf program type. That imho is another bad design decision.

What should've happend is that device access management should've just
been implemented through the bpf-LSM infrastructure. That way all this
stuff would've gone through security_inode_permission() instead of us
having to have two separate calls in inode_permission().

I would love to kill this call. And cgroup v1 is deprecated and systemd
has dropped any support for it last year as well.

> 
> the file seems to have no maintainer fwiw
> 
> anyhow I'm confident the way forward is to add IOP_FAST_MAY_EXEC (or
> similar) to elide inode_permission() in the common case to begin with.
> There are quite a few branches which straight up don't need execute.

Yes.

> On top of that btrfs has a permission hook only to check for MAY_WRITE,
> which in case of path lookup is not set. With the above flag the call
> will be avoided.
> 
> Mateusz Guzik (2):
>   fs: touch up predicts in inode_permission()
>   device_cgroup: avoid access to ->i_rdev in the common case in
>     devcgroup_inode_permission()
> 
>  fs/namei.c                    | 10 +++++-----
>  include/linux/device_cgroup.h |  7 ++++---
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> -- 
> 2.48.1
>