linux-kernel - Re: [RFC PATCH] vfs: dodge strlen() in vfs_readlink() when ->i

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: <CAGudoHHJwreaSZirs6qfQw5-qRnyHsFLeKp_=T2=S_J=VezKLg@mail.gmail.com>
Date: Mon, 18 Nov 2024 21:32:33 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Jan Kara <jack@...e.cz>, brauner@...nel.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH] vfs: dodge strlen() in vfs_readlink() when ->i_link
 is populated

On Mon, Nov 18, 2024 at 4:44 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Mon, Nov 18, 2024 at 03:51:34PM +0100, Mateusz Guzik wrote:
>
> > This is only 1.5% because of other weird slowdowns which don't need to
> > be there, notably putname using atomics. If the other crap was already
> > fixed it would be closer to 5%.
>
> Describe your plans re putname(), please.  Because we are pretty much
> certain to step on each other's toes here in the coming cycle.

I don't have immediate plans for putname, but I posted a total hack
some time ago in relation to it:
https://lore.kernel.org/all/20240604132448.101183-1-mjguzik@gmail.com/

along with this:
> The race is only possible with io_uring which has a dedicated entry
> point, thus a getname variant which takes it into account could store
> the need to use atomics as a flag in struct filename. To that end
> getname could take a boolean indicating this, fronted with some inlines
> and the current entry point renamed to __getname_flags to hide it.

> Option B is to add a routine which "upgrades" to atomics after getname
> returns, but that's a littly fishy vs audit_reusename.

> At the end of the day all spots which modify the ref could branch on the
> atomics flag.

I ended up not getting this done because there was something real off
about name caching for audit, I don't remember the details but I was
not confident the code is correct as is.

Anyhow, someone else sorting this out is most welcome.

Apart from the few things I posted I have no immediate plans to mess
with anything vfs (I do have some plans to reduce the cost of memcg
though).

-- 
Mateusz Guzik <mjguzik gmail.com>