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

Message-ID: <5490118a-7185-44fe-b816-b01c8ff75979@intel.com>
Date: Wed, 24 Sep 2025 11:32:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Fam Zheng <fam.zheng@...edance.com>
Cc: 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>, fam@...hon.net,
 "H. Peter Anvin" <hpa@...or.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 9/24/25 09:21, Fam Zheng wrote:
...
> The model and motivation here is not to split the domain and give
> different shares to different sysadmins, it's intended for one kernel
> to partition itself. I agree we shouldn't have different kernels here:
> one old, one new, one Linux, one Windows... All partitions should run
> a verified parker-aware kernel. Actually, it may be a good idea to
> force the same buildid in kexec between the boot kernel and secondary
> ones.
Uhhh.... From the cover letter:

> Another possible use case is for different kernel instances to have
> different performance tunings, CONFIG_ options, FDO/PGO according to
> the workload.

Wouldn't the buildid change with CONIFG_ options and FDO/PGO?

Thank you for posting this series. It's interesting and a thought
provoking. But, that's where it stops for me. I don't think this
approach has any future upstream. I probably won't look at it again,
even if it hits my inbox. (I hope it _isn't_ sent again unless there is
some *MAJOR* *MAJOR* change to the approach).