linux-kernel - Re: [PATCH 00/21] mm: ASI direct map management

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] [day] [month] [year] [list]

Message-ID: <fc52e463-5704-4713-9c91-1e4fa0d58047@redhat.com>
Date: Thu, 2 Oct 2025 09:34:59 +0200
From: David Hildenbrand <david@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>, Brendan Jackman
 <jackmanb@...gle.com>, 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>
Cc: peterz@...radead.org, bp@...en8.de, dave.hansen@...ux.intel.com,
 mingo@...hat.com, tglx@...utronix.de, akpm@...ux-foundation.org,
 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 00/21] mm: ASI direct map management

On 01.10.25 22:59, Dave Hansen wrote:
> On 9/24/25 07:59, Brendan Jackman wrote:
>> Why is this the scope of the first series? The objective here is to
>> reach a MVP of ASI that people can actually run, as soon as possible.
> 
> I had to ask ChatGPT what you meant by MVP. Minimum Viable Product?
> 
> So this series just creates a new address space and then ensures that
> sensitive data is not mapped there? To me, that's a proof-of-concept,
> not a bit of valuable functionality that can be merged upstream.
> 
> I'm curious how far the first bit of functionality that would be useful
> to end users is from the end of this series.

There was this mail "[Discuss] First steps for ASI (ASI is fast 
again)"[1] that I also didn't get to fully digest yet, where there was a 
question at the very end

"
Once we have some x86 maintainers saying "yep, it looks like this can 
work and it's something we want", I can start turning my page_alloc RFC 
[3] into a proper patchset (or maybe multiple if I can find a way to 
break things down further).

...

So, x86 folks: Does this feel like "line of sight" to you? If not, what 
would that look like, what experiments should I run?
"

Unless I am missing something, no x86 maintainer replied to that one so 
far and I assume this patch set here is the revival of above mentioned RFC
"

so it might be reasonable to reply there.

[1] 
https://lore.kernel.org/all/20250812173109.295750-1-jackmanb@google.com/T/#u

-- 
Cheers

David / dhildenb