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: <CAG+v+KZ4bRgVNiMDhNTeiOqqbEXCBD72K5SQZCo=m0xaQ2vauQ@mail.gmail.com>
Date: Wed, 24 Sep 2025 17:21:13 +0100
From: Fam Zheng <fam.zheng@...edance.com>
To: Dave Hansen <dave.hansen@...el.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 Wed, Sep 24, 2025 at 4:23 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 9/23/25 08:31, Fam Zheng wrote:
> > In terms of fault isolation or security, all kernel instances share
> > the same domain, as there is no supervising mechanism. A kernel bug
> > in any partition can cause problems for the whole physical machine.
> > This is a tradeoff for low-overhead / low-complexity, but hope in
> > the future we can take advantage of some hardware mechanism to
> > introduce some isolation.
> I just don't think this is approach is viable. The buck needs to stop
> _somewhere_. You can't just have a bunch of different kernels, with
> nothing in charge of the system as a whole.
>
> Just think of bus locks. They affect the whole system. What if one
> kernel turns off split lock detection? Or has a different rate limit
> than the others? What if one kernel is a big fan of WBINVD? How about
> when they use resctrl to partition an L3 cache? How about microcode updates?

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.

Fam