From: David Hildenbrand <david@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>,
Cong Wang <xiyou.wangcong@gmail.com>
Cc: linux-kernel@vger.kernel.org, pasha.tatashin@soleen.com,
Cong Wang <cwang@multikernel.io>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Alexander Graf <graf@amazon.com>,
Mike Rapoport <rppt@kernel.org>,
Changyuan Lyu <changyuanl@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
multikernel@lists.linux.dev
Subject: Re: [RFC Patch 0/7] kernel: Introduce multikernel architecture support
Date: Wed, 24 Sep 2025 13:38:31 +0200 [thread overview]
Message-ID: <3b1a1b17-9a93-47c6-99a1-43639cd05cbf@redhat.com> (raw)
In-Reply-To: <20250923170545.GA509965@fedora>
>>
>> Two more points:
>>
>> 1) Security lockdown. Security lockdown transforms multikernel from
>> "0-day means total compromise" to "0-day means single workload
>> compromise with rapid recovery." This is still a significant improvement
>> over containers where a single kernel 0-day compromises everything
>> simultaneously.
>
> I don't follow. My understanding is that multikernel currently does not
> prevent spawned kernels from affecting each other, so a kernel 0-day in
> multikernel still compromises everything?
I would assume that if there is no enforced isolation by the hardware
(e.g., virtualization, including partitioning hypervisors like
jailhouse, pkvm etc) nothing would stop a kernel A to access memory
assigned to kernel B.
And of course, memory is just one of the resources that would not be
properly isolated.
Not sure if encrypting memory per kernel would really allow to not let
other kernels still damage such kernels.
Also, what stops a kernel to just reboot the whole machine? Happy to
learn how that will be handled such that there is proper isolation.
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-09-24 11:38 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 22:25 Cong Wang
2025-09-18 22:26 ` [RFC Patch 1/7] kexec: Introduce multikernel support via kexec Cong Wang
2025-09-18 22:26 ` [RFC Patch 2/7] x86: Introduce SMP INIT trampoline for multikernel CPU bootstrap Cong Wang
2025-09-18 22:26 ` [RFC Patch 3/7] x86: Introduce MULTIKERNEL_VECTOR for inter-kernel communication Cong Wang
2025-09-18 22:26 ` [RFC Patch 4/7] kernel: Introduce generic multikernel IPI communication framework Cong Wang
2025-09-18 22:26 ` [RFC Patch 5/7] x86: Introduce arch_cpu_physical_id() to obtain physical CPU ID Cong Wang
2025-09-18 22:26 ` [RFC Patch 6/7] kexec: Implement dynamic kimage tracking Cong Wang
2025-09-18 22:26 ` [RFC Patch 7/7] kexec: Add /proc/multikernel interface for " Cong Wang
2025-09-19 10:10 ` [syzbot ci] Re: kernel: Introduce multikernel architecture support syzbot ci
2025-09-19 13:14 ` [RFC Patch 0/7] " Pasha Tatashin
2025-09-20 21:13 ` Cong Wang
2025-09-19 21:26 ` Stefan Hajnoczi
2025-09-20 21:40 ` Cong Wang
2025-09-22 14:28 ` Stefan Hajnoczi
2025-09-22 22:41 ` Cong Wang
2025-09-23 17:05 ` Stefan Hajnoczi
2025-09-24 11:38 ` David Hildenbrand [this message]
2025-09-24 12:51 ` Stefan Hajnoczi
2025-09-24 18:28 ` Cong Wang
2025-09-24 19:03 ` Stefan Hajnoczi
2025-09-27 19:42 ` Cong Wang
2025-09-29 15:11 ` Stefan Hajnoczi
2025-10-02 4:17 ` Cong Wang
2025-09-24 17:18 ` Cong Wang
2025-09-21 1:47 ` Hillf Danton
2025-09-22 21:55 ` Cong Wang
2025-09-24 1:12 ` Hillf Danton
2025-09-24 17:30 ` Cong Wang
2025-09-24 22:42 ` Hillf Danton
2025-09-21 5:54 ` Jan Engelhardt
2025-09-21 6:24 ` Mike Rapoport
2025-09-24 17:51 ` Christoph Lameter (Ampere)
2025-09-24 18:39 ` Cong Wang
2025-09-26 9:50 ` Jarkko Sakkinen
2025-09-27 20:43 ` Cong Wang
2025-09-28 14:22 ` Jarkko Sakkinen
2025-09-28 14:36 ` Jarkko Sakkinen
2025-09-28 14:41 ` Jarkko Sakkinen
2025-09-25 15:47 ` Jiaxun Yang
2025-09-27 20:06 ` Cong Wang
2025-09-26 9:01 ` Jarkko Sakkinen
2025-09-27 20:27 ` Cong Wang
2025-09-27 20:39 ` Pasha Tatashin
2025-09-28 14:08 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3b1a1b17-9a93-47c6-99a1-43639cd05cbf@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=changyuanl@google.com \
--cc=cwang@multikernel.io \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=multikernel@lists.linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=stefanha@redhat.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox