Move the declaration of PaddedSevHashTable before SevSnpGuest so
we can add a new such field to the latter.
No functional change intended.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions
Cc: Eric Blake
Cc: Markus Armbruster
Cc: Marcelo Tosatti
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Tom Lendacky
Cc: Michael Roth
Cc: Ashish Kalra
Cc: Mario Smarduch
Cc: Tobin Feldman-Fitzthum
Dov Murik (4):
qapi, i386: Move kernel-hashes to SevCommonProperties
i386/sev: Extract
for SEV
launch secrets which are not usable anyway on SNP.
If the user disabled kernel hashes, QEMU pre-validates the kernel hashes
page as a zero page.
Signed-off-by: Dov Murik
---
include/hw/i386/pc.h | 2 ++
target/i386/sev.c| 40
2 files changed
Extract the building of the kernel hashes table out from
sev_add_kernel_loader_hashes() to allow building it in
other memory areas (for SNP support).
No functional change intended.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 110 ++
1 file
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
Signed-off-by: Dov Murik
---
qapi/qom.json | 12 ++--
target/i386/sev.c | 44 ++--
2
Hello Markus,
On 16/02/2023 11:24, Markus Armbruster wrote:
> Dov Murik writes:
>
>> In order to enable kernel-hashes for SNP, pull it from
>> SevGuestProperties to its parent SevCommonProperties so
>> it will be available for both SEV and SNP.
>
> Missing
&
On 16/02/2023 10:49, Dov Murik wrote:
> This RFC patch series is based on AMD's RFC upmv10-snpv3 tree [1].
>
Note that in order to test this you must use '-machine pc-q35-7.1'
to circumvent the SETUP_RNG_SEED bug [1] that interferes with the
measured kernel.
[1] https://lore.kernel.or
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
---
qapi/qom.json | 12 ++--
target/i386/sev.c | 44 ++--
2 files changed, 24
disabled kernel hashes, QEMU pre-validates the page as a
zero page.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 51 +--
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 6b8e85888f
Smarduch
Cc: Tobin Feldman-Fitzthum
Dov Murik (2):
qapi, i386: Move kernel-hashes to SevCommonProperties
i386/sev: Allow measured direct kernel boot on SNP
qapi/qom.json | 12 +++---
target/i386/sev.c | 95 +--
2 files changed, 65 insertions(+), 42
On 09/02/2023 8:03, Dov Murik wrote:
> Hi Michael,
>
> On 08/02/2023 23:12, Michael S. Tsirkin wrote:
>> All attempts to fix up passing RNG seed via setup_data entry failed.
>> Let's just rip out all of it. We'll start over.
>>
>>
>> Warning: all I
files changed, 49 insertions(+), 161 deletions(-)
>
I tested this series with SEV measured boot using AmdSev OVMF. The boot
succeeds, and the hashes computed for kernel/initrd/cmdline are
identical to the ones computed by qemu 7.1.0, which are the hashes that
the guest owner would expect.
As for non-EFI (non-SEV) guests, I did a very simple test of starting a
non-EFI guest and it looks OK, but more testing is needed.
So:
Tested-by: Dov Murik
Thank you!
-Dov
while leaving intact the infrastructure we'll need in the future to try
> again.
>
> Cc: Michael S. Tsirkin
> Cc: Dov Murik
> Cc: Tom Lendacky
> Cc: Gerd Hoffmann
> Cc: Daniel P. Berrangé
> Cc: Paolo Bonzini
> Cc: Richard Henderson
> Cc: H. Peter Anvin
> Cc
On 08/02/2023 17:49, Dov Murik wrote:
> But I now think there's another bug with the current patches:
>
>
> /*
>* Add the NUL terminator, some padding for the microvm cmdline fiddling
>* hack, and then align to 16 bytes as a paranoia measure
>*/
>
On 08/02/2023 17:26, Tom Lendacky wrote:
> On 2/7/23 17:24, Jason A. Donenfeld wrote:
>> Hi Tom,
>>
>> On Tue, Feb 7, 2023 at 8:21 PM Tom Lendacky
>> wrote:
>>>
>>> On 2/7/23 15:45, Michael S. Tsirkin wrote:
>>>> On Tue, Feb 07, 2023 a
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 d
On 08/02/2023 1:24, Jason A. Donenfeld wrote:
> Hi Tom,
>
> On Tue, Feb 7, 2023 at 8:21 PM Tom Lendacky wrote:
>>
>> On 2/7/23 15:45, Michael S. Tsirkin wrote:
>>> On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
>>>> Recent feature to su
Hi Daniel,
On 08/02/2023 11:30, Daniel P. Berrangé 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 b
>>> On Tue, Feb 07, 2023 at 04:45:19PM -0500, Michael S. Tsirkin wrote:
>>>>> On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
>>>>>> Recent feature to supply RNG seed to the guest kernel modifies the
>>>>>> kernel comman
Signed-off-by: Dov Murik
---
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_
Hi Jason, James,
On 01/02/2023 17:24, James Bottomley wrote:
> On Wed, 2023-02-01 at 10:10 -0500, Jason A. Donenfeld wrote:
>> This is already fixed via the patch that MST just sent in his pull.
>> So wait a few days for that to be merged and it'll be all set.
>>
>> No need for this patch here.
On 19/04/2022 10:16, Dov Murik wrote:
> Thanks Paolo.
>
> On 19/04/2022 8:50, Paolo Bonzini wrote:
>> From: Dov Murik
>>
>> Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
>> command. The value of the field is the base64-encoded uniqu
Commit 811b4ec7f8eb ("qapi, target/i386/sev: Add cpu0-id to
query-sev-capabilities") wrongly stated that the new field is available
since version 7.0.
Fix the QAPI documentation to state that the cpu0-id field is included
since 7.1.
Signed-off-by: Dov Murik
---
qapi/misc-target.json
Thanks Paolo.
On 19/04/2022 8:50, Paolo Bonzini wrote:
> From: Dov Murik
>
> Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
> command. The value of the field is the base64-encoded unique ID of CPU0
> (socket 0), which can be used to retrieve the signed
Hi Cole,
On 13/04/2022 16:36, Cole Robinson wrote:
> Hi all,
>
> SEV-ES and SEV-SNP attestation require a copy of the initial VMSA to
> validate the launch measurement. For developers dipping their toe into
> SEV-* work, the easiest way to get sample VMSA data for their machine is
> to grab it
On 07/04/2022 8:55, Markus Armbruster wrote:
> Cole Robinson writes:
>
>> On 2/28/22 4:39 AM, Dov Murik wrote:
>>>
>>>
>>> On 28/02/2022 11:31, Daniel P. Berrangé wrote:
>>>> On Mon, Feb 28, 2022 at 09:30:14AM +, Dov Murik wrote:
>&
/devel/message/88137
Signed-off-by: Dov Murik
---
target/i386/sev.c | 40
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 3c296a59ae..dbc9d570a9 100644
--- a/target/i386/sev.c
+++ b/target/i386
On 28/02/2022 11:31, Daniel P. Berrangé wrote:
> On Mon, Feb 28, 2022 at 09:30:14AM +0000, Dov Murik wrote:
>> Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
>> command. The value of the field is the base64-encoded unique ID of CPU0
>> (socket
Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
command. The value of the field is the base64-encoded unique ID of CPU0
(socket 0), which can be used to retrieve the signed CEK of the CPU from
AMD's Key Distribution Service (KDS).
Signed-off-by: Dov Murik
---
v3
On 24/02/2022 10:59, Daniel P. Berrangé wrote:
> On Thu, Feb 24, 2022 at 06:14:05AM +0000, Dov Murik wrote:
>> Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
>> command. The value of the field is the base64-encoded 64-byte unique ID
>> of the CPU0
Add a new field 'cpu0-id' to the response of query-sev-capabilities QMP
command. The value of the field is the base64-encoded 64-byte unique ID
of the CPU0 (socket 0), which can be used to retrieve the signed CEK of
the CPU from AMD's Key Distribution Service (KDS).
Signed-off-by: Dov Murik
:
- simplify bounds check and remove max_tot_len (thanks Dave)
- split one patch to two
v2:
- add error message example to commit description
- replace magic numbers 48 and 50 with size calculations (thanks Phil
MD)
Dov Murik (2):
hw/i386: Improve bounds checking in OVMF table parsing
hw/i386: Replace
table, and add an error report
in case the size is invalid. In such a case, an error like this will be
displayed during launch:
qemu-system-x86_64: OVMF table has invalid size 4047
and the table parsing is skipped.
Signed-off-by: Dov Murik
---
hw/i386/pc_sysfw_ovmf.c | 9 -
1 file
Replce the literal magic number 48 with length calculation (32 bytes at
the end of the firmware after the table footer + 16 bytes of the OVMF
table footer GUID).
No functional change intended.
Signed-off-by: Dov Murik
---
hw/i386/pc_sysfw_ovmf.c | 9 ++---
1 file changed, 6 insertions
Thanks Dave for reviewing.
On 21/02/2022 21:44, Dr. David Alan Gilbert wrote:
> * Dov Murik (dovmu...@linux.ibm.com) wrote:
>> When pc_system_parse_ovmf_flash() parses the optional GUIDed table in
>> the end of the OVMF flash memory area, the table length field is check
Thanks Daniel for reviewing.
On 21/02/2022 18:24, Daniel P. Berrangé wrote:
> On Mon, Feb 21, 2022 at 04:08:50PM +0000, Dov Murik wrote:
>> Add a new field 'cpu0-id' to the response of query-sev-capabilities
>> QMP command. The value of the field is the hex-encoded 64-by
Add a new field 'cpu0-id' to the response of query-sev-capabilities
QMP command. The value of the field is the hex-encoded 64-byte unique
ID of the CPU0 (socket 0), which can be used to retrieve the signed CEK
of the CPU from AMD's Key Distribution Service (KDS).
Signed-off-by: Dov Murik
Add a section explaining how the Guest Owner should calculate the
expected guest launch measurement for SEV and SEV-ES.
Also update the name and links to the SEV API Spec document.
Signed-off-by: Dov Murik
Suggested-by: Daniel P. Berrangé
---
v2:
- Explain that firmware must be built without
table, and add an error report
in case the size is invalid. In such a case, an error like this will be
displayed during launch:
qemu-system-x86_64: OVMF table has invalid size 4047
and the table parsing is skipped.
Signed-off-by: Dov Murik
---
v2:
- add error message example to commit
On 04/01/2022 20:00, Daniel P. Berrangé wrote:
> On Mon, Dec 20, 2021 at 10:42:24AM +0000, Dov Murik wrote:
>> Add a section explaining how the Guest Owner should calculate the
>> expected guest launch measurement for SEV and SEV-ES.
>>
>> Also update the name a
On 04/01/2022 20:07, Daniel P. Berrangé wrote:
> On Mon, Jan 03, 2022 at 11:14:13AM +0200, Dov Murik wrote:
>> Add docs/specs/sev-guest-firmware.rst which describes the GUIDed table
>> in the end of OVMF's image which is parsed by QEMU, and currently used
>> to describ
table, and add an error report
in case the size is invalid.
Signed-off-by: Dov Murik
---
hw/i386/pc_sysfw_ovmf.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_sysfw_ovmf.c b/hw/i386/pc_sysfw_ovmf.c
index f4dd92c588..0663f3f54a 100644
--- a/hw/i386
On 31/01/2022 16:26, Daniel P. Berrangé wrote:
[...]
>
> IOW, I think there's only two scenarios that make sense
>
> 1. The combined launch digest over firmware, kernel hashes
>and VMSA state.
>
> 2. Individual hashes for each of firmware, kernel hashes table and
>VMSA state
>
On 31/01/2022 13:44, Daniel P. Berrangé wrote:
> On Mon, Jan 31, 2022 at 11:15:39AM +0000, Dov Murik wrote:
>> Currently the responses of QMP commands query-sev-launch-measure and
>> query-sev-attestation-report return just the signed measurement. In
>> order to validat
that the value of debug-launch-digest should not be used for
verifying the measurement, because it is not signed. Hence the choice
of the 'debug-' prefix for the field's name.
Suggested-by: Tobin Feldman-Fitzthum
Signed-off-by: Dov Murik
---
Implementation note: I keep a buffer (sev->launch_mem
[+cc Tom, Brijesh, Ashish - see SEV-related changes in this series]
On 13/01/2022 18:55, Daniel P. Berrangé wrote:
> The AMD SEV build of EDK2 only emits a single file, intended to be
>
> mapped readonly. There is explicitly no separate writable VARS
>
> store for persisting non-volatile
On 07/01/2022 22:18, Daniel P. Berrangé wrote:
> On Thu, Dec 16, 2021 at 11:41:27PM +0200, Dov Murik wrote:
>>
>>
>> On 16/12/2021 18:09, Daniel P. Berrangé wrote:
>>> On Thu, Dec 16, 2021 at 12:38:34PM +0200, Dov Murik wrote:
>>>>
>>>&
Add docs/specs/sev-guest-firmware.rst which describes the GUIDed table
in the end of OVMF's image which is parsed by QEMU, and currently used
to describe some values for SEV and SEV-ES guests.
Signed-off-by: Dov Murik
---
docs/specs/index.rst | 1 +
docs/specs/sev-guest
Add a section explaining how the Guest Owner should calculate the
expected guest launch measurement for SEV and SEV-ES.
Also update the name and link to the SEV API Spec document.
Signed-off-by: Dov Murik
Suggested-by: Daniel P. Berrangé
---
v2:
- Explain that firmware must be built without
Add docs/specs/sev-guest-firmware.rst which describes the GUIDed table
in the end of OVMF's image which is parsed by QEMU, and currently used
to describe some values for SEV and SEV-ES guests.
Signed-off-by: Dov Murik
---
docs/specs/index.rst | 1 +
docs/specs/sev-guest
On 16/12/2021 18:09, Daniel P. Berrangé wrote:
> On Thu, Dec 16, 2021 at 12:38:34PM +0200, Dov Murik wrote:
>>
>>
>> On 14/12/2021 20:39, Daniel P. Berrangé wrote:
>>> On Tue, Dec 14, 2021 at 01:59:10PM +, Dov Murik wrote:
>>>> Add a section expla
On 14/12/2021 20:39, Daniel P. Berrangé wrote:
> On Tue, Dec 14, 2021 at 01:59:10PM +0000, Dov Murik wrote:
>> Add a section explaining how the Guest Owner should calculate the
>> expected guest launch measurement for SEV and SEV-ES.
>>
>> Also update the name a
Add a section explaining how the Guest Owner should calculate the
expected guest launch measurement for SEV and SEV-ES.
Also update the name and link to the SEV API Spec document.
Signed-off-by: Dov Murik
Suggested-by: Daniel P. Berrangé
---
docs/amd-memory-encryption.txt | 50
On 25/11/2021 18:08, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> On Thu, Nov 25, 2021 at 03:40:36PM +, Dr. David Alan Gilbert wrote:
>>> * Sergio Lopez (s...@redhat.com) wrote:
>>>> On Thu, Nov 25, 2021 at 02:
[+cc Tom, Brijesh]
On 25/11/2021 15:42, Daniel P. Berrangé wrote:
> On Thu, Nov 25, 2021 at 02:44:51PM +0200, Dov Murik wrote:
>> [+cc jejb, tobin, jim, hubertus]
>>
>>
>> On 25/11/2021 9:14, Sergio Lopez wrote:
>>> On Wed, Nov 24, 2021 at 06:29:07PM
On 25/11/2021 15:52, Daniel P. Berrangé wrote:
> On Thu, Nov 25, 2021 at 08:14:28AM +0100, Sergio Lopez wrote:
>> For SEV-SNP, this is pretty much the end of the story, because the
>> attestation exchange is driven by an agent inside the guest. Well,
>> there's also the need to have in the VM a
On 25/11/2021 15:27, Daniel P. Berrangé wrote:
> On Wed, Nov 24, 2021 at 06:29:07PM +, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>>> On Wed, Nov 24, 2021 at 11:34:16AM -0500, Tyler Fanelli wrote:
Hi,
We recently discussed a way for
[+cc jejb, tobin, jim, hubertus]
On 25/11/2021 9:14, Sergio Lopez wrote:
> On Wed, Nov 24, 2021 at 06:29:07PM +, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>>> On Wed, Nov 24, 2021 at 11:34:16AM -0500, Tyler Fanelli wrote:
Hi,
We
On 18/11/2021 15:02, Daniel P. Berrangé wrote:
> On Thu, Nov 18, 2021 at 02:21:09PM +0200, Dov Murik wrote:
>> Pinging again -- Daniel said this should be added to 6.2.
>>
>> Is there anything I should do?
>
> I'm going to take care of sending a PULL to relieve Pao
Pinging again -- Daniel said this should be added to 6.2.
Is there anything I should do?
Thanks,
-Dov
On 14/11/2021 20:02, Dov Murik wrote:
> Paolo,
>
> Can you please add this series (already reviewed) to the fixes in 6.2?
>
> Thanks,
> -Dov
>
>
> On 11/11/
Paolo,
Can you please add this series (already reviewed) to the fixes in 6.2?
Thanks,
-Dov
On 11/11/2021 12:00, Dov Murik wrote:
> Tom Lendacky and Brijesh Singh reported two issues with launching SEV
> guests with the -kernel QEMU option when an old [1] or wrongly configured [2]
> OV
On 11/11/2021 11:39, Daniel P. Berrangé wrote:
> On Mon, Nov 08, 2021 at 01:48:34PM +0000, Dov Murik wrote:
>> Tom Lendacky and Brijesh Singh reported two issues with launching SEV
>> guests with the -kernel QEMU option when an old [1] or wrongly configured [2]
>>
Introduce new boolean 'kernel-hashes' option on the sev-guest object.
It will be used to to decide whether to add the hashes of
kernel/initrd/cmdline to SEV guest memory when booting with -kernel.
The default value is 'off'.
Signed-off-by: Dov Murik
Reviewed-by: Daniel P. Berrangé
Acked
Rephrase error message when no hashes table GUID is found.
- Replace qemu_map_ram_ptr with address_space_map
v1:
https://lore.kernel.org/qemu-devel/20211101102136.1706421-1-dovmu...@linux.ibm.com/
Dov Murik (6):
qapi/qom,target/i386: sev-guest: Introduce kernel-hashes=on|off option
target/i
Use address_space_map/unmap and check for errors.
Signed-off-by: Dov Murik
Reviewed-by: Daniel P. Berrangé
Acked-by: Brijesh Singh
---
target/i386/sev.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 4fd258a570
ro, or its size is too small to fit the aligned hashes
table, display an error and stop the guest launch. In such case, the
following error will be displayed:
qemu-system-x86_64: SEV: guest firmware hashes table area is invalid
(base=0x0 size=0x0)
Signed-off-by: Dov Murik
Reported-by: Bri
won't fill that area.
To enable addition of kernel hashes, launch the guest with:
-object sev-guest,...,kernel-hashes=on
Signed-off-by: Dov Murik
Reported-by: Tom Lendacky
Reviewed-by: Daniel P. Berrangé
Acked-by: Brijesh Singh
---
target/i386/sev.c | 8
1 file changed, 8 insertion
Signed-off-by: Dov Murik
Acked-by: Brijesh Singh
---
target/i386/sev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index e3abbeef68..6ff196f7ad 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -1232,7 +1232,8 @@ bool
In sev_add_kernel_loader_hashes, the sizes of structs are known at
compile-time, so calculate needed padding at compile-time.
No functional change intended.
Signed-off-by: Dov Murik
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Acked
On 11/11/2021 11:26, Daniel P. Berrangé wrote:
> On Mon, Nov 08, 2021 at 08:20:48PM +0200, Dov Murik wrote:
>>
>>
>> On 08/11/2021 17:51, Markus Armbruster wrote:
>>> Dov Murik writes:
>>>
>>>> Introduce new boolean 'kernel-hashes' o
On 08/11/2021 23:22, Brijesh Singh wrote:
>
>
> On 11/5/21 1:32 PM, Dov Murik wrote:
>>
>>
>> On 02/11/2021 16:48, Brijesh Singh wrote:
>>>
>>>
>>> On 11/2/21 8:22 AM, Dov Murik wrote:
>>>>
>>>>
>>>> O
On 08/11/2021 17:51, Markus Armbruster wrote:
> Dov Murik writes:
>
>> Introduce new boolean 'kernel-hashes' option on the sev-guest object.
>> It will be used to to decide whether to add the hashes of
>> kernel/initrd/cmdline to SEV guest memory when booting with
On 08/11/2021 15:53, Daniel P. Berrangé wrote:
> On Mon, Nov 08, 2021 at 01:48:37PM +0000, Dov Murik wrote:
>> Signed-off-by: Dov Murik
>> ---
>> target/i386/sev.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/
ssage when no hashes table GUID is found.
- Replace qemu_map_ram_ptr with address_space_map
v1:
https://lore.kernel.org/qemu-devel/20211101102136.1706421-1-dovmu...@linux.ibm.com/
Dov Murik (6):
qapi/qom,target/i386: sev-guest: Introduce kernel-hashes=on|off option
target/i386/sev: Add kerne
won't fill that area.
To enable addition of kernel hashes, launch the guest with:
-object sev-guest,...,kernel-hashes=on
Signed-off-by: Dov Murik
Reported-by: Tom Lendacky
---
target/i386/sev.c | 8
1 file changed, 8 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/s
Use address_space_map/unmap and check for errors.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 2e3a6e8ff8..12f28e878c 100644
--- a/target/i386/sev.c
+++ b/target
Signed-off-by: Dov Murik
---
target/i386/sev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index e3abbeef68..c71d23654f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -1232,7 +1232,8 @@ bool sev_add_kernel_loader_hashes
Introduce new boolean 'kernel-hashes' option on the sev-guest object.
It will be used to to decide whether to add the hashes of
kernel/initrd/cmdline to SEV guest memory when booting with -kernel.
The default value is 'off'.
Signed-off-by: Dov Murik
---
qapi/qom.json | 7 ++-
target
ro, or its size is too small to fit the aligned hashes
table, display an error and stop the guest launch. In such case, the
following error will be displayed:
qemu-system-x86_64: SEV: guest firmware hashes table area is invalid
(base=0x0 size=0x0)
Signed-off-by: Dov Murik
Reported-by: Bri
In sev_add_kernel_loader_hashes, the sizes of structs are known at
compile-time, so calculate needed padding at compile-time.
No functional change intended.
Signed-off-by: Dov Murik
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Philippe Mathieu-Daudé
---
target/i386/sev.c | 28
On 02/11/2021 16:48, Brijesh Singh wrote:
>
>
> On 11/2/21 8:22 AM, Dov Murik wrote:
>>
>>
>> On 02/11/2021 12:52, Brijesh Singh wrote:
>>> Hi Dov,
>>>
>>> Overall the patch looks good, only question I have is that now we are
&
On 03/11/2021 18:07, Daniel P. Berrangé wrote:
> On Mon, Nov 01, 2021 at 10:21:35AM +0000, Dov Murik wrote:
>> Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes
>> for measured linux boot", 2021-09-30) introduced measured direct boot
>&
On 04/11/2021 20:22, Daniel P. Berrangé wrote:
> On Thu, Nov 04, 2021 at 06:18:10PM +, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>>> On Mon, Nov 01, 2021 at 10:21:34AM +, Dov Murik wrote:
>>>> Commit cff0
On 03/11/2021 17:44, Brijesh Singh wrote:
>
>
> On 11/3/21 9:08 AM, Dr. David Alan Gilbert wrote:
>> * Brijesh Singh (brijesh.si...@amd.com) wrote:
>>>
>>>
>>> On 11/2/21 8:22 AM, Dov Murik wrote:
>>>>
>>>>
>>>&g
and how can OVMF tell.
How about: QEMU always prevalidates this page (either fills it with
zeros or with the hashes table), and the BIOS always excludes it?
-Dov
>
> Thoughts ?
>
> thanks
>
> On 11/1/21 5:21 AM, Dov Murik wrote:
>> Tom Lendacky and Brijesh Singh reported tw
On 02/11/2021 14:36, Dr. David Alan Gilbert wrote:
> * Dov Murik (dovmu...@linux.ibm.com) wrote:
>> Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes
>> for measured linux boot", 2021-09-30) introduced measured direct boot
>> with -kernel,
On 02/11/2021 13:36, Dr. David Alan Gilbert wrote:
> * Dov Murik (dovmu...@linux.ibm.com) wrote:
>> In sev_add_kernel_loader_hashes, the sizes of structs are known at
>> compile-time, so calculate needed padding at compile-time.
>>
>> No functional change intende
On 01/11/2021 16:25, Tom Lendacky wrote:
> On 11/1/21 5:21 AM, Dov Murik wrote:
>> Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes
>> for measured linux boot", 2021-09-30) introduced measured direct boot
>> with -kernel, using an OVMF-des
ro, or its size is too small to fit the aligned hashes
table, warn and skip the hashes entries addition. In such case, the
following warning will be displayed:
qemu-system-x86_64: warning: SEV: OVMF's hashes table area is invalid
(base=0x0 size=0x0)
Signed-off-by: Dov Murik
Reported-by: Bri
On 28/10/2021 11:41, Dov Murik wrote:
>
>
> On 27/10/2021 22:43, Brijesh Singh wrote:
>> Hi Dov,
>>
>> Sorry for coming a bit late on it but I am seeing another issue with
>> this patch. The hash build logic looks for a SEV_HASH_TABLE_RV_GUID in
>> th
emu-system-x86_64: warning: SEV: kernel specified but OVMF has no hash
table guid
Signed-off-by: Dov Murik
Reported-by: Tom Lendacky
---
target/i386/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index eede07f11d..682b8cc
-devel/001dd81a-282d-c307-a657-e228480d4...@amd.com/
Dov Murik (3):
sev/i386: Allow launching with -kernel if no OVMF hashes table found
sev/i386: Warn if using -kernel with invalid OVMF hashes table area
sev/i386: Perform padding calculations at compile-time
target/i386/sev.c | 34
In sev_add_kernel_loader_hashes, the sizes of structs are known at
compile-time, so calculate needed padding at compile-time.
No functional change intended.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff
boot.
Separately I'll try to solve the issue in the other OVMF *.fdf's.
Thanks for reporting this.
-Dov
>
> Thanks
> Brijesh
>
> On 10/20/21 10:26 AM, Tom Lendacky wrote:
>> On 10/19/21 1:18 AM, Dov Murik wrote:
>>> On 18/10/2021 21
On 18/10/2021 21:02, Tom Lendacky wrote:
> On 9/30/21 12:49 AM, Dov Murik wrote:
>
> ...
>
>> +/*
>> + * Add the hashes of the linux kernel/initrd/cmdline to an encrypted
>> guest page
>> + * which is included in SEV's initial memory measurement.
>>
On 07/10/2021 19:28, Dov Murik wrote:
>
>
> On 07/10/2021 19:17, Philippe Mathieu-Daudé wrote:
>> Use g_autofree to remove a pair of g_free/goto.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> target/i386/sev.c | 13 -
>>
The struct kvm_sev_launch_start has a constant and small size, and
therefore we can use a regular local variable for it instead of
allocating and freeing heap memory for it.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 23 ++-
1 file changed, 10 insertions(+), 13
-phi...@redhat.com/
Dov Murik (2):
target/i386/sev: Use local variable for kvm_sev_launch_start
target/i386/sev: Use local variable for kvm_sev_launch_measure
target/i386/sev.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
--
2.25.1
The struct kvm_sev_launch_measure has a constant and small size, and
therefore we can use a regular local variable for it instead of
allocating and freeing heap memory for it.
Signed-off-by: Dov Murik
---
target/i386/sev.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions
On 07/10/2021 19:17, Philippe Mathieu-Daudé wrote:
> Use g_autofree to remove a pair of g_free/goto.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/i386/sev.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/target/i386/sev.c
1 - 100 of 235 matches
Mail list logo
