linux-kernel - Re: [PATCH v4 0/4] x86/snp: Add kexec support

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: <26b3b3b5-548d-4ebd-9d21-19580a41e799@amazon.com>
Date: Thu, 2 May 2024 14:01:08 +0200
From: Alexander Graf <graf@...zon.com>
To: Ashish Kalra <Ashish.Kalra@....com>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
	<x86@...nel.org>
CC: <rafael@...nel.org>, <peterz@...radead.org>, <adrian.hunter@...el.com>,
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, <jun.nakajima@...el.com>,
	<rick.p.edgecombe@...el.com>, <thomas.lendacky@....com>,
	<michael.roth@....com>, <seanjc@...gle.com>, <kai.huang@...el.com>,
	<bhe@...hat.com>, <kirill.shutemov@...ux.intel.com>, <bdas@...hat.com>,
	<vkuznets@...hat.com>, <dionnaglaze@...gle.com>, <anisinha@...hat.com>,
	<jroedel@...e.de>, <ardb@...nel.org>, <kexec@...ts.infradead.org>,
	<linux-coco@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/4] x86/snp: Add kexec support

Hey Ashish,

On 09.04.24 22:42, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@....com>
>
> The patchset adds bits and pieces to get kexec (and crashkernel) work on
> SNP guest.

With this patch set (and similar for the TDX one), you enable the 
typical kdump case, which is great!

However, if a user is running with direct kernel boot - which is very 
typical in SEV-SNP setup, especially for Kata Containers and similar - 
the initial launch measurement is a natural indicator of the target 
environment. Kexec basically allows them to completely bypass that: You 
would be able to run a completely different environment than the one you 
measure through the launch digest. I'm not sure it's a good idea to even 
allow that by default in CoCo environments - at least not if the kernel 
is locked down.

Do you have any plans to build a CoCo native kexec where you allow a VM 
to create a new VM context with a guest provided seed? The new context 
could rerun all of the attestation and so enable users to generate a new 
launch digest. If you then atomically swap into the new context, it 
would in turn enable them to natively "kexec" into a completely new VM 
context including measurements.

I understand that an SVSM + TPM implementation may help to some extent 
here by integrating with IMA and adding the new kernel into the IMA log. 
But that quickly becomes very convoluted (hence difficult to assess 
correctness for) and the same measurement question arises just one level 
up then: How do you update your SVSM while maintaining a full 
measurement and trust chain?

Thanks,

Alex