linux-kernel - Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT

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: <3635aacd-04e6-4873-961c-0b1fc09d2353@lucifer.local>
Date: Thu, 15 May 2025 19:21:02 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        David Hildenbrand <david@...hat.com>,
        Usama Arif <usamaarif642@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        hannes@...xchg.org, shakeel.butt@...ux.dev, riel@...riel.com,
        ziy@...dia.com, laoar.shao@...il.com, baolin.wang@...ux.alibaba.com,
        npache@...hat.com, ryan.roberts@....com, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT_HUGE for the
 process

On Thu, May 15, 2025 at 02:09:56PM -0400, Liam R. Howlett wrote:
> * David Hildenbrand <david@...hat.com> [250515 13:30]:
> > > >
> > >
> > > Did we document all this? :)
> > >
> > > It'd be good to be super explicit about these sorts of 'dependency chains'.
> > >
> >
> > Documentation/admin-guide/mm/transhuge.rst has under "Global THP controls"
> > quite some stuff about all that, yes.
> >
> > The whole document needs an overhaul, to clarify on the whole terminology,
> > make it consistent, and better explain how the pagecache behaves etc. On my
> > todo list, but I'm afraid it will be a bit of work to get it right / please
> > most people.
>
> Yes, the whole thing is making me grumpy (more than my default state).
> The more I think about it, the more I don't like the prctl approach
> either...

prctl() feels like it's literally never, ever the right choice.

It feels like we shove all the dark stuff we want to put under the rug
there.

Reading the man page is genuinely frightening. there's stuff about VMAs _I
wasn't aware of_.

It's also never really the _right time_ to do it - it's not process
inception is it? It's when the process has started, now you suddenly fiddle
with it.

Then relying on mm flags being propagated over fork/exec is just, it's a
hack really.

>
> I more than dislike flags2... I hate it.

Yeah, to be clear - I will NACK any series that tries to add flags2 unless
a VERY VERY good justification is given. It's horrid. And frankly this
feature doesn't warrant something as horrible.

But making mm->flags 64-bit on 32-bit kernels (which are in effect
deprecated in my view) would fix this.

>
> but no prctl, no cgroups, no bpf.. what is left?  A new policy groups
> thing?  No, not that either, please.

A new clone[,2,3]() flag?

process_madvise() feels literally made for this, but at the same time only
lets you do a small range at a time.

Some ability to default a process's madvise() state on VMA inception and
having a new syscall for that could be a thing, but then is that prctl()
wearing a hat...

>
> To state the obvious, none of this is transparent.

Indeed...

>
> Regards,
> Liam
>
>

I'm worried about knock on effects too, now we have a way to force-set VMA
flags.

And a working version of this series will involve literally hard-coding
this stuff into the VMA logic and 'just remembering' to always set it up
right on new VMA inception.

It's all very horrible.

I guess going to RFC is also about testing for _feasibility_ of this as an
idea.

But let's explore and assess, maybe there's some way of making this work
that isn't horrid...

I feel like it exposes some weaknesses on policy setting anyway that maybe
we need to think about more deeply.

pidfd to the rescue?? Somehow?? ;)