linux-kernel - Re: [External] Re: [RFC 0/5] parker: PARtitioned KERnel

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: <113902a5-a635-4d21-8192-8c6d482e88bf@zytor.com>
Date: Thu, 25 Sep 2025 08:32:21 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Fam Zheng <fam.zheng@...edance.com>
Cc: fam@...hon.net, Dave Hansen <dave.hansen@...el.com>,
        linux-kernel@...r.kernel.org, Lukasz Luba <lukasz.luba@....com>,
        linyongting@...edance.com, songmuchun@...edance.com,
        satish.kumar@...edance.com, Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>, yuanzhu@...edance.com,
        Ingo Molnar <mingo@...hat.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Zhang Rui <rui.zhang@...el.com>, x86@...nel.org, liangma@...edance.com,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>, guojinhui.liam@...edance.com,
        linux-pm@...r.kernel.org, Thom Hughes <thom.hughes@...edance.com>
Subject: Re: [External] Re: [RFC 0/5] parker: PARtitioned KERnel

On 2025-09-25 00:26, Fam Zheng wrote:
>> From: "H. Peter Anvin"<hpa@...or.com>
>> The difference is that this is highly invasive to the OS, which affects developers and users not wanting this feature.
> 
> Yeah that makes sense, thanks for clarifying. By having a hypervisor
> at least in early boot of secondary kernels, we don't need to patch
> device enumeration etc. In the kernel code.
> 
> Once the kernel is up, it can be then promoted to run directly on bare
> metal, so zero performance overhead.

Realistically you would remain in the hypervisor, but nothing or almost
nothing will trap into the hypervisor, so again, zero or negligible
performance overhead.  You also *can* put some isolation or protection
features in the low-level hypervisor.

The important thing here is that the maintenance burden *and* the policy
choices fall on the users of the feature, and as the upstream maintainers
cannot and thus will not test this use case, it is likely to break on a
regular basis.

This is basically "paravirt_ops all over again." There are very good reasons
we are trying to get rid of them.

	-hpa