On 3/2/23, Al Viro [off-list ref] wrote:

On Thu, Mar 02, 2023 at 07:14:24PM +0100, Mateusz Guzik wrote:

quoted

On 3/2/23, Linus Torvalds [off-list ref] wrote:

quoted

On Thu, Mar 2, 2023 at 12:30 AM Christian Brauner [off-list ref]
wrote:

quoted

Fwiw, as long as you, Al, and others are fine with it and I'm aware of
it I'm happy to pick up more stuff like this. I've done it before and
have worked in this area so I'm happy to help with some of the load.

Yeah, that would work. We've actually had discussions of vfs
maintenance in general.

In this case it really wasn't an issue, with this being just two
fairly straightforward patches for code that I was familiar with.

Well on that note I intend to write a patch which would add a flag to
the dentry cache.

There is this thing named CONFIG_INIT_ON_ALLOC_DEFAULT_ON which is
enabled at least on debian, ubuntu and arch. It results in mandatory
memset on the obj before it gets returned from kmalloc, for hardening
purposes.

Now the problem is that dentry cache allocates bufs 4096 bytes in
size, so this is an equivalent of a clear_page call and it happens
*every time* there is a path lookup.

Huh?  Quite a few path lookups don't end up allocating any dentries;
what exactly are you talking about?

Ops, I meant "names_cache", here:
	names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0,
			SLAB_HWCACHE_ALIGN|SLAB_PANIC, 0, PATH_MAX, NULL);

it is fs/dcache.c and I brainfarted into the above.

quoted

Given how dentry cache is used, I'm confident there is 0 hardening
benefit for it.

So the plan would be to add a flag on cache creation to exempt it from
the mandatory memset treatment and use it with dentry.

I don't have numbers handy but as you can imagine it gave me a nice bump
:)

Whatever you think about the idea aside, the q is: can something like
the above go in without Al approving it?

That one I would really like to take a look at.

allright

-- 
Mateusz Guzik <mjguzik gmail.com>