Received-SPF: pass (google.com: domain of linux-kernel+bounces-166984-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <a1aaf894-02cb-4018-8a65-525f6f8f918a@amd.com>
Date: Thu, 2 May 2024 16:54:41 -0500
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/4] x86/snp: Add kexec support
Content-Language: en-US
To: Alexander Graf <graf@amazon.com>, tglx@linutronix.de, mingo@redhat.com,
 bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org
Cc: rafael@kernel.org, peterz@infradead.org, adrian.hunter@intel.com,
 sathyanarayanan.kuppuswamy@linux.intel.com, jun.nakajima@intel.com,
 rick.p.edgecombe@intel.com, thomas.lendacky@amd.com, michael.roth@amd.com,
 seanjc@google.com, kai.huang@intel.com, bhe@redhat.com,
 kirill.shutemov@linux.intel.com, bdas@redhat.com, vkuznets@redhat.com,
 dionnaglaze@google.com, anisinha@redhat.com, jroedel@suse.de,
 ardb@kernel.org, kexec@lists.infradead.org, linux-coco@lists.linux.dev,
 linux-kernel@vger.kernel.org
References: <20240409113010.465412-1-kirill.shutemov@linux.intel.com>
 <cover.1712694667.git.ashish.kalra@amd.com>
 <26b3b3b5-548d-4ebd-9d21-19580a41e799@amazon.com>
From: "Kalra, Ashish" <ashish.kalra@amd.com>
In-Reply-To: <26b3b3b5-548d-4ebd-9d21-19580a41e799@amazon.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NEtXaGI0NXd3RDEzdEdUaFY5NDVpR2RrNmVGZXYzU1BhNzd1c21YcnJMNGFw?=
 =?utf-8?B?MVNYbFZpRStzV3lldjJtMVFDQVNnTUJiY2ZPdjV2SVVtd1NxT0V5emloTzF0?=
 =?utf-8?B?K2ZKc3RTZG82dUlDRUhweVJ5UEdWdTBWdlNzdUZVRFpUNnZrQ1JzSkU5VXYx?=
 =?utf-8?B?RHl0Y0lhWUphT0lSUEhCdzVIWS96ZjdNZU04aUpaanA5dDFUZ3ZvYWRFdlZX?=
 =?utf-8?B?a2xZYlkyQ2tPMk9XRjhWTUZnR29INmtnZVVpZ3BBR2M1K3l2SUZSK0s5QUhU?=
 =?utf-8?B?cnhRUDdJWk9mYjFXVWZZRFZKTGtMTVo2SEl4WTMvTFJjWUkrSnFncDlwMjBM?=
 =?utf-8?B?cFRFb0owSE1mSnBPdnhGdVFyYWxIS0JXS1JWektkaVZ4L3F4RHR2OGFESU5j?=
 =?utf-8?B?ZTgrcDlHV1ZrR0pCZjVwOWp2OGZzMDkybC9jYnlxZ25RL3VoOGpuMC9xS0hU?=
 =?utf-8?B?ZVdDU2F5WHM5YUhVaXlIU0hkcGZFMGNtRFJma2JqYlJ6T2hWSGZhMG53VWhn?=
 =?utf-8?B?N2tMTTkrL09IWndKTEo3SUdzWUhZd1hjQ0FiaUdrTm0rNlFFT2REQjllU29S?=
 =?utf-8?B?WTFIVlBFaWEzSmR6blVpS2dnZlR6UWtXSWwvQWpBaklmWW5HQzVVQ0JtMzdk?=
 =?utf-8?B?V3h6RzRrRTlGdVhZQ1dObVZVeGltNkFmTk1sK0V4bjhTVGtUMUtMV2VPWE5m?=
 =?utf-8?B?RDUrODB1QWxPK3Nob3VMRmJyRnh4bjAyaEt2VTV2NGtPU050TldCd0JQQjBj?=
 =?utf-8?B?WEhVQjUyRFNyNHd1bmtxbkk5TExENm1ZUElka2tqbFpFeS9yRHJTbkJUaGll?=
 =?utf-8?B?YWlwTWJZTkNQNWl2cDdlOVBOOXJWSzVrYnBwOHROblYxMEt5Sml6aEFJT3dC?=
 =?utf-8?B?VWEyZWpzMEQ4NlNrWjVNZUpiNjgxemlUSEFiTDUxQ0VZdGR3b0I1QUVzV1BR?=
 =?utf-8?B?KzZXWG9HcU1PVFptSzgxdzJvZEJJelRQTVltMGJxZGp6eWlXVTQ3bVQwbVUv?=
 =?utf-8?B?eDJjSWdDZjhZdGtpMUhySGkzclo5NHllZ00vWlhzckV6SW9HSitJNDRpeStW?=
 =?utf-8?B?aTJ5bmNYR3FwYWNMb2NlblpvQnNoNUJCeVFUSnQxdUJ5WERsbFluYURJZDNt?=
 =?utf-8?B?eFRFd2dhcmdQcXJjMzZMUjFZTW5FVWlLQWRvWVNLaVRLN3pGendnZk9xQ1dw?=
 =?utf-8?B?OW50eTFmSTdWS3h1THJXNHBqMWxmdjRFcng0eE5PNGtoV3QzTmdVck1KbkZS?=
 =?utf-8?B?OHM3UjNhNXJVbGlJUzRCekhKSkFFS2E0bXhsVnFFTHYxTm1TT2g5b0JYSmNs?=
 =?utf-8?B?R2dxVUYreEdhL3BTZlNyVkpCc3dSVXIvcFU5WER0d2dKVTd0UmtIUjNBVlFm?=
 =?utf-8?B?LzlZK2xiZUNlQ3RvaVdrYTdmUTVUZUp0T09tZHJzQWNtbFl3NUU2V0NjN1F3?=
 =?utf-8?B?ZnhEeXVJRnJaU29Yb21NbCt5OEVmNlVzTzRnclV6RzdmRXFkOGpKSmpUU1RU?=
 =?utf-8?B?dkVKUFdPVkM0eEhNRmRpaGRVZ2lXZEFubTVQTGxDQW1Tcy9ta2pOVVBmS295?=
 =?utf-8?B?eWNQVG9CWUlWSkhrdWlwZXp2NFNIR0QvS05VQkVLUnNDS3NSdGZidjdHc1Yv?=
 =?utf-8?B?OCtvdnZmLzhBVzlOYnB5WFlUQzduZmJaalpyaG5tK05zNWNjYUl3V25ubS9x?=
 =?utf-8?B?emhJQVZyd2dhenRtZVcrSGlkZEpKdG44UjJhZnpnQzgzT2NGeXIrK1Bjb3Ey?=
 =?utf-8?B?cWVMWExYS0FMODhrdkZna3BlUlpoSXlIZTJ2ZHd2TWk0aUIxWlB3d1JUKzlp?=
 =?utf-8?B?U3hMb2VZQkRqeFh1QjBmYkkvaVNHajNKajhCY01Kclk4YXpGODUzelFvcVFE?=
 =?utf-8?B?aVA1dnJYMGg0cVFuWEFWMDMvTU5VS040RnFwb2FhZjhuMGZoWGJpaXBMVXBD?=
 =?utf-8?B?NzZ6TzhhMDluZWE0Y1JlR2hML1hJbzJ0QzV0ZzVPQU5wQ1h6WXYwRkNZUHAr?=
 =?utf-8?B?TnIxa0hzQlM4V1EwdzFZdHMzZm11WWNLUzBVS2ZzZTFhQ240N045ZGwvRlhI?=
 =?utf-8?B?YnpPcXRDMFNSbXNORy9UZ1g0amo3S0IzK3VaWHdROHRZSk4rQ1QwUzB1M2d4?=
 =?utf-8?Q?M7T5MkPa9scGlVp0zy2rsXdxz?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96562c17-f518-487c-0154-08dc6af279e7
X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2767.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2024 21:54:44.1245
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: q6LrGcqBm2JzpoESdIqFZO1VObL3IZRlihEROaT5CW7iUXcl++979KbDJIktBRc3LgiFughE9BTR8fpAIqOB/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5800

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