linux-kernel - Re: [PATCH v2 6/6] alloc_tag: config to store page allocation tag refs in page flags

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: <70ef75d9-a573-4989-9a9d-c8bc087f212b@nvidia.com>
Date: Tue, 3 Sep 2024 19:05:52 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Suren Baghdasaryan <surenb@...gle.com>, Andrew Morton
	<akpm@...ux-foundation.org>
CC: <kent.overstreet@...ux.dev>, <corbet@....net>, <arnd@...db.de>,
	<mcgrof@...nel.org>, <rppt@...nel.org>, <paulmck@...nel.org>,
	<thuth@...hat.com>, <tglx@...utronix.de>, <bp@...en8.de>,
	<xiongwei.song@...driver.com>, <ardb@...nel.org>, <david@...hat.com>,
	<vbabka@...e.cz>, <mhocko@...e.com>, <hannes@...xchg.org>,
	<roman.gushchin@...ux.dev>, <dave@...olabs.net>, <willy@...radead.org>,
	<liam.howlett@...cle.com>, <pasha.tatashin@...een.com>,
	<souravpanda@...gle.com>, <keescook@...omium.org>, <dennis@...nel.org>,
	<yuzhao@...gle.com>, <vvvvvv@...gle.com>, <rostedt@...dmis.org>,
	<iamjoonsoo.kim@....com>, <rientjes@...gle.com>, <minchan@...gle.com>,
	<kaleshsingh@...gle.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-arch@...r.kernel.org>,
	<linux-mm@...ck.org>, <linux-modules@...r.kernel.org>,
	<kernel-team@...roid.com>
Subject: Re: [PATCH v2 6/6] alloc_tag: config to store page allocation tag
 refs in page flags

On 9/3/24 6:25 PM, John Hubbard wrote:
> On 9/3/24 11:19 AM, Suren Baghdasaryan wrote:
>> On Sun, Sep 1, 2024 at 10:16 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>>> On Sun,  1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan <surenb@...gle.com> wrote:
> ...
>>> We shouldn't be offering things like this to our users.  If we cannot decide, how
>>> can they?
>>
>> Thinking about the ease of use, the CONFIG_PGALLOC_TAG_REF_BITS is the
>> hardest one to set. The user does not know how many page allocations

I should probably clarify my previous reply, so here is the more detailed
version:

>> are there. I think I can simplify this by trying to use all unused
>> page flag bits for addressing the tags. Then, after compilation we can

Yes.

>> follow the rules I mentioned before:
>> - If the available bits are not enough to address all kernel page
>> allocations, we issue an error. The user should disable
>> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS.

The configuration should disable itself, in this case. But if that is
too big of a change for now, I suppose we could fall back to an error
message to the effect of, "please disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS
because the kernel build system is still too primitive to do that for you". :)


>> - If there are enough unused bits but we have to push last_cpupid out
>> of page flags, we issue a warning and continue. The user can disable
>> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS if last_cpupid has to stay in page
>> flags.

Let's try to decide now, what that tradeoff should be. Just pick one based
on what some of us perceive to be the expected usefulness and frequency of
use between last_cpuid and these tag refs.

If someone really needs to change the tradeoff for that one bit, then that
someone is also likely able to hack up a change for it.

thanks,
-- 
John Hubbard

>> - If we run out of addressing space during module loading, we disable
>> allocation tagging and continue. The user should disable
>> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS.
> 
> If the computer already knows what to do, it should do it, rather than
> prompting the user to disable a deeply mystifying config parameter.
> 
>>
>> This leaves one outstanding case:
>> - If we run out of addressing space during module loading but we would
>> not run out of space if we pushed last_cpupid out of page flags during
>> compilation.
>> In this case I would want the user to have an option to request a
>> larger addressing space for page allocation tags at compile time.
>> Maybe I can keep CONFIG_PGALLOC_TAG_REF_BITS for such explicit
>> requests for a larger space? This would limit the use of
>> CONFIG_PGALLOC_TAG_REF_BITS to this case only. In all other cases the
>> number of bits would be set automatically. WDYT?
> 
> Manually dealing with something like this is just not going to work.
> 
> The more I read this story, the clearer it becomes that this should be
> entirely done by the build system: set it, or don't set it, automatically.
> 
> And if you can make it not even a kconfig item at all, that's probably even
> better.
> 
> And if there is no way to set it automatically, then that probably means
> that the feature is still too raw to unleash upon the world.
> 
> thanks,