linux-kernel - Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression

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: <20240703-haftstrafe-anbringen-88ed445e77a4@brauner>
Date: Wed, 3 Jul 2024 16:08:56 +0200
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	Linux Memory Management List <linux-mm@...ck.org>, linux-kernel@...r.kernel.org, ying.huang@...el.com, 
	feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput
 -33.7% regression

> As a side note this is where I should also note the *current* LSM hooks
> are racy as is.  Suppose you can stat a particular file now, but a chown
> to 1234 means you can't. Then your stat call can race against chown +
> other ops. You can end up in a state where LSMs gave a green light and
> only then the state changed to one you are not allowed to look at. This

Fwiw, we've discussed this before. And my opinion is that we should
absolute not care about this. I have no interest in complicating path
lookup or any codepath to make these hooks less racy. This raciness they
have to deal with. This is not a comment on your patch but just that the
raciness of security hooks is not a problem we should care to solve
imho. If we go down that road we'll all slowly go insane trying to give
state change guarantees to layers that hook into the VFS in really odd
locations.