linux-kernel - Re: [PATCH 02/21] x86/mm/asi: add X86_FEATURE

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: <20251110112640.GVaRHL8GME4ODowica@fat_crate.local>
Date: Mon, 10 Nov 2025 12:26:40 +0100
From: Borislav Petkov <bp@...en8.de>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Andy Lutomirski <luto@...nel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...e.com>,
	Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>, peterz@...radead.org,
	dave.hansen@...ux.intel.com, mingo@...hat.com, tglx@...utronix.de,
	akpm@...ux-foundation.org, david@...hat.com, derkling@...gle.com,
	junaids@...gle.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, reijiw@...gle.com, rientjes@...gle.com,
	rppt@...nel.org, vbabka@...e.cz, x86@...nel.org,
	Yosry Ahmed <yosry.ahmed@...ux.dev>
Subject: Re: [PATCH 02/21] x86/mm/asi: add X86_FEATURE_ASI and asi=

On Sun, Oct 26, 2025 at 10:24:35PM +0000, Brendan Jackman wrote:
> Hm yeah, I actually also thought I had some direct feedback from one of
> the x86 maintainers saying not to expose it here. I can no longer find
> that feedback on Lore so I think I must be misremembering, the flag
> was already hidden back in [0].
> 
> [0] https://lore.kernel.org/linux-mm/20240712-asi-rfc-24-v1-5-144b319a40d8@google.com/
> 
> If that feedback indeed doesn't exist

Just ignore everything whoever might've told you or not - we override all
previous statements! :-P

>From Documentation/arch/x86/cpuinfo.rst

"So, the current use of /proc/cpuinfo is to show features which the
kernel has *enabled* and *supports*. As in: the CPUID feature flag is
there, there's an additional setup which the kernel has done while
booting and the functionality is ready to use. A perfect example for
that is "user_shstk" where additional code enablement is present in the
kernel to support shadow stack for user programs."

So it is all written down now and is the law! :-P

> then personally I'd lean towards exposing it right away, I don't see that
> much downside in terms of ABI, since ASI kinda "doesn't do anything", from
> a SW point of view it's just a very weird and complicated NOP. It's hard for
> me to see how userspace could grow a functional dependency on this flag.
> Whereas for general monitoring it's handy.

The point is: once all the ASI code lands, we should show it in cpuinfo. As
in: "this kernel supports ASI" and not "there's asi in cpuinfo but well,
that's not the whole deal."

Makes sense?

> > Not an early_param() ?
> 
> Oh this is just for consistency with pti_check_boottime_disable(). But,
> I think that function actually exists because of init ordering issues
> that aren't relevant here, so early_param() seems fine to me (or, if I
> find some reason why it doesn't, work, I'll add a comment in v2 to
> explain why we don't use it).

Ack.

> Thanks for taking a look :)

Sure, np.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette