qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86: Don't add RNG seed to Linux cmdline for SEV guests


From: Dov Murik
Subject: Re: [PATCH] x86: Don't add RNG seed to Linux cmdline for SEV guests
Date: Wed, 8 Feb 2023 13:57:33 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1


On 08/02/2023 1:21, Tom Lendacky wrote:
> On 2/7/23 15:45, Michael S. Tsirkin wrote:
>> On Tue, Feb 07, 2023 at 08:41:16AM +0000, Dov Murik wrote:
>>> Recent feature to supply RNG seed to the guest kernel modifies the
>>> kernel command-line by adding extra data at its end; this breaks
>>> measured boot with SEV and OVMF, and possibly signed boot.
>>>
>>> Specifically SEV doesn't miss this feature because it uses UEFI/OVMF
>>> which has its own way of getting random seed (not to mention that
>>> getting the random seed from the untrusted host breaks the confidential
>>> computing trust model).
>>
>> Nope - getting a random seed from an untrusted source should not break
>> anything assuming you also have some other randomness source.
>> If you don't then you have other problems.
>>
>>> Disable the RNG seed feature in SEV guests.
>>>
>>> Fixes: eac7a7791bb6 ("x86: don't let decompressed kernel image
>>> clobber setup_data")
>>> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
>>> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
>>>
>>> ---
>>>
>>> There might be a need for a wider change to the ways setup_data entries
>>> are handled in x86_load_linux(); here I just try to restore the
>>> situation for SEV guests prior to the addition of the SETUP_RNG_SEED
>>> entry.
>>>
>>> Recent discussions on other (safer?) ways to pass this setup_data entry:
>>> [1]
>>> da39abab9785aea2a2e7652ed6403b6268aeb31f.camel@linux.ibm.com/">https://lore.kernel.org/qemu-devel/da39abab9785aea2a2e7652ed6403b6268aeb31f.camel@linux.ibm.com/
>>>
>>> Note that in qemu 7.2.0 this is broken as well -- there the
>>> SETUP_RNG_SEED entry is appended to the Linux kernel data (and therefore
>>> modifies and breaks the measurement of the kernel in SEV measured boot).
>>> A similar fix will be needed there (but I fear this patch cannot be
>>> applied as-is).
>>
>> So it's not a regression, is it?
> 
> SEV kernel hash comparison succeeded with Qemu v7.1.0, but fails with
> v7.2.0, so I think that is a regression.
> 

I see the same behaviour.


Also this was observed by the Confidential Containers project, which
uses kata-containers with QEMU to start SEV guest VMs; they downgraded
[1] from 7.2.0 to 7.1.0 until the issue is solved.

[1] https://github.com/kata-containers/kata-containers/pull/6191


They said they can backport a patch once it's upstream in qemu, but
since the RNG-seed code has changed a lot since 7.2.0, the patch that
we'll add in master will not be applicable as-is to 7.2.0.

I'm not sure if there's intention to release a 7.2.1 or who decides
about this.

-Dov



reply via email to

[Prev in Thread] Current Thread [Next in Thread]