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: <a1aaf894-02cb-4018-8a65-525f6f8f918a@amd.com>
Date: Thu, 2 May 2024 16:54:41 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Alexander Graf <graf@...zon.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

Hello Alexander,

On 5/2/2024 7:01 AM, Alexander Graf wrote:
> 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.
>
I thought that kexec is disabled if kernel is in locked-down mode.

Or is it that KEXEC_LOAD syscall is not supported/disabled in kernel 
locked-down mode and KEXEC_FILE_LOAD syscall is supported ?

> 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.

No, currently i don't think there any any such plans.

Thanks, Ashish

>
> 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
>