Error: Can't find SEV_ES_RESET_BLOCK_GUID entry in OVMF table

[LucaStabo]

I am trying to run the sev-snp-measure tool in SNP mode using the example in the readme: sev-snp-measure --mode snp --vcpus=1 --vcpu-type=EPYC-v4 --ovmf=OVMF.fd --kernel=vmlinuz --initrd=initrd.img --append="console=ttyS0 loglevel=7"

but i get the following error: Error: Can't find SEV_ES_RESET_BLOCK_GUID entry in OVMF table

the type of the OVMF.fd file is the following: file OVMF.fd OVMF.fd: Matlab v4 mat-file (little endian) \226v\213L\251\205'G\007[OP, numeric, rows 0, columns 0

i tried with different images but the problem always seems to be the OVMF.fd file. what could be the cause of the error? is there a specific format that i have to use ?

[dubek]

The SEV_ES_RESET_BLOCK_GUID exists in OVMF builds for more than 3 years, if I recall correctly. Unless something changed recently that removed it... Are you able to boot the SNP VM with this OVMF.fd? How did you build/obtain OVMF.fd ? Currently, for SNP, you should follow the instructions in https://github.com/AMDESE/AMDSEV/tree/snp-latest .

[LucaStabo]

Yes i am following the instruction of https://github.com/AMDESE/AMDSEV/tree/snp-latest . And i am also able to boot the SNP VM with the OVMF.fd file. But then when i try to run the sev-snp-measure tool i still get that error message.

[dubek]

Interesting. Maybe you can post your OVMF.fd somewhere that I can download and experiment with.

[LucaStabo]

hi, yes here is the file. https://drive.google.com/file/d/1_4A5ON1cPUgm6nntCXWoUwEaflCtLbHW/view?usp=drive_link

[dubek]

Thanks @LucaStabo for providing the file.

It is very weird:

First, the image.fd file is only 540672 bytes long. Usually OVMF builds are 3-4 MB.

Second, the file is full of 0xff bytes:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  8d 2b f1 ff 96 76 8b 4c  a9 85 27 47 07 5b 4f 50  |.+...v.L..'G.[OP|
...
...
00004140  aa 0d 00 e0 98 03 2b 8c  42 00 6f 00 6f 00 74 00  |......+.B.o.o.t.|
00004150  4f 00 72 00 64 00 65 00  72 00 00 00 03 00 00 00  |O.r.d.e.r.......|
00004160  01 00 02 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00004170  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00041000  2b 29 58 9e 68 7c 7d 49  a0 ce 65 00 fd 9f 1b 95  |+)X.h|}I..e.....|
00041010  2c af 2c 64 fe ff ff ff  e0 0f 00 00 00 00 00 00  |,.,d............|
00041020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00084000

(these * lines means that the last line is repeated)

Third, the last 32 bytes should include the "VTF\0" signature. Here's the end of one of the "normal" OVMFs:

% hexdump -Cv svsm_ovmf.fd | tail -3
0037bfe0  e9 22 ff 90 90 90 90 90  00 00 00 00 56 54 46 00  |."..........VTF.|
0037bff0  0f 20 c0 a8 01 74 05 e9  21 ff ff ff e9 01 ff 90  |. ...t..!.......|
0037c000

but the image.fd you provided doesn't have the "VTF\0":

% hexdump -Cv bad/image.fd | tail -3
00083fe0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00083ff0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00084000

You say that you're able to boot SNP VM with this OVMF file. Can you share the QEMU command-line that refers to that file and successfully boots an SNP VM?

Maybe there's a mix-up between OVMF_VARS and OVMF_CODE files?

[LucaStabo]

Hi, i followed the instruction of : https://github.com/AMDESE/AMDSEV/tree/snp-latest after creating an empty 10G qcow2 image file, i downloaded an official ubuntu server .iso file and i run the command ./launch-qemu.sh -hda <your_qcow2_file> -cdrom <your_distro_installation_iso_file> to launch it, i used : ./launch-qemu.sh -hda <your_qcow2_file> -sev-snp

[dubek]

@larrydewey Any idea why the instructions in AMDSEV will generate an OVMF build that is only ~500KB and contains mostly 0xff bytes? And how could that successfully launch an SNP VM?

[dubek]

@LucaStabo Please make sure again that the file you use is the OVMF_CODE.fd generated by the build process (and not OVMF_VARS.fd).

[LucaStabo]

i tryed again and OVMF_CODE.fd and OVMF_VARS.fd are correct. any other reasons why this could be happening?

[dubek]

@LucaStabo Can you please paste again the size OVMF_CODE.fd (in bytes) and the hexdump of the last 32 bytes of OVMF_CODE.fd ?