Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with Recalculating Measurement from Attestation Report in Guest Machine on the Host Machine #37

Closed
steve-237 opened this issue Jan 21, 2024 · 14 comments

Comments

@steve-237
Copy link

I am encountering an issue while attempting to recalculate the measurement from the attestation report within the guest machine. Below are the details of the problem:

I have installed the guest machine, a virtual machine, using the AMDSEV project from the GitHub user AMDESE. After successfully installing the guest machine, I executed it using the command:

sudo ./launch-qemu.sh -hda sev-guest.qcow2 -sev-snp

Following the execution of the guest machine, I utilized the 'snpguest' tool to generate the attestation report. The report contains the measurement, represented by the hash:

d7b9f49e254f5d3eeda91e2966ad68504c2b54710ff6a21d05bc1279bfd77aba8de2e582a00eaebb37c004be12c37830.

Subsequently, I attempted to recalculate this hash (measurement) from the host machine using the 'sev-snp-measurement' tool with the following command:

./sev-snp-measure.py --mode snp --vcpus=1 --vcpu-type=EPYC-v4 --vmm-type=QEMU --ovmf=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd --kernel=/home/user/AMDSEV/sev-guest.fd --initrd=/home/user/AMDSEV/sev-guest.qcow2 --append="console=ttyS0 loglevel=7" --snp-ovmf-hash=711dd640bc679fcdefa729f47ff56700c95b1c590a779391ab178d511d6237677bea447327923972c4eee313fc2f915d

However, I encountered the following error:

"Error: Kernel specified but OVMF metadata doesn't include SNP_KERNEL_HASHES section."

This has led me to question the correctness of the kernel path, initrd value, and other parameters.

  1. Where can I find the correct values to use for the parameters( kernel path, initrd path, append,..) mentioned above please ?

Additionally, when using the 'sev-snp-measure.py' tool with the command:

./sev-snp-measure.py --mode snp --vcpus=1 --vcpu-type=EPYC-v4 --vmm-type=QEMU --ovmf=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd --snp-ovmf-hash=711dd640bc679fcdefa729f47ff56700c95b1c590a779391ab178d511d6237677bea447327923972c4eee313fc2f915d

I get a value that does not match the measurement in the attestation report within the guest machine.

  1. How can I accurately recalculate the value of this measurement?

Any guidance or assistance on resolving this issue and accurately recalculating the measurement would be highly appreciated.

@fitzthum
Copy link
Collaborator

Calculating the expected measurement can be a little bit unforgiving. I see a couple issues the steps you followed.

First, if you are using the AMDESE/AMDSEV tools, you are probably only measuring the firmware of your guest so don't use any of the flags for things that are not the firmware i.e. kernel, append. If you would like to measure those pieces, we support a measured direct boot approach. This will require you to use different firmware. If you specify the kernel flag but do not have the appropriate firmware you will get the error that you see. Your best bet is to start with only measuring the firmware.

If you specify the --ovmf flag, there is no need to use the --snp-ovmf-hash flag. The --snp-ovmf-hash is used when you have precalculated the hash of OVMF using the snp:ovmf-hash mode. For now it's simpler to just provide the firmware directly with the OVMF flag.

You might have more issues, but I'd start with those.

@dubek
Copy link
Member

dubek commented Jan 22, 2024

  1. It looks like you're using OVMF which doesn't support kernel hashes, and therefore you shouldn't include --kernel, --initrd, and --append arguments to sev-snp-measure, because they are not included in the launch measurement.
  2. Try setting --vcpus=4 -- it looks like the default setting for launch-qemu.sh. Also you can remove --snp-ovmf-hash if you supply the full OVMF file with --ovmf.

If that doesn't work, please supply more details on were you got launch-qemu.sh and sev-guest.qcow2 -- exactly which repo and branch.

@dubek
Copy link
Member

dubek commented Jan 22, 2024

@fitzthum you beat me to it... 1-0 in the first half.

@fitzthum
Copy link
Collaborator

Wow that was a close one.

@steve-237
Copy link
Author

Thank you @fitzthum and @dubek for your thorough guidance and suggestions. I truly appreciate your time and effort in helping me navigate through this challenge.

I will carefully implement the adjustments you recommended, excluding non-firmware flags and omitting the --snp-ovmf-hash flag while specifying --ovmf. I am eager to see the results of these changes.

I will reattempt the process shortly and will revert to you promptly with an update on the outcomes. If I encounter any further difficulties or have additional questions, I will not hesitate to seek your valuable guidance.

Once again, thank you for your support, and I look forward to being in touch soon.

@steve-237
Copy link
Author

Hello @dubek and @fitzthum, thank you again for your guidance. The launch script I used originates from the AMDSEV repository, specifically from the following location: https://github.com/AMDESE/AMDSEV/tree/snp-latest, and I pulled it from the branch 'snp-latest.'

Despite following your previous suggestions, I still encountered a hash discrepancy. To provide additional context, I executed the following command:
./sev-snp-measure.py --mode snp --vcpus=4 --vcpu-type=EPYC-v4 --ovmf=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd
The resulting hash was 47246d40591cdc7433a67639809fc824d0398912f32ed600b1222111a1d01f2cb94eaf26ca7008cea5141168dbbfa027, which differs from the expected value d7b9f49e254f5d3eeda91e2966ad68504c2b54710ff6a21d05bc1279bfd77aba8de2e582a00eaebb37c004be12c37830.

In light of this, I would appreciate further guidance on resolving this discrepancy.

Could you suggest specific alternative firmware options suitable for the measured direct boot approach, particularly when measuring components like the kernel and append? Specifically, information on where to acquire such firmware and details about the recommended branch and tools would be immensely helpful.

Thank you

@dubek
Copy link
Member

dubek commented Jan 24, 2024

It might help to post the entire qemu command-line that is executed by launch-qemu.sh (should be printed to the console before the VM starts up).

@dubek
Copy link
Member

dubek commented Jan 24, 2024

Also see the thread in AMDESE/AMDSEV#195 - there's a new feature called debug_swap which should either be disabled on KVM, or you should modify sev-snp-measure to account for it (see our WIP PR #32).

FYI @larrydewey

@steve-237
Copy link
Author

Here is the qemu command-line :

/home/user/AMDSEV/user/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=255 -m 2048M,slots=5,maxmem=10240M -no-reboot -drive if=pflash,format=raw,unit=0,file=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd,readonly -drive if=pflash,format=raw,unit=1,file=/home/user/AMDSEV/sev-guest.fd -drive file=/home/user/AMDSEV/sev-guest.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object memory-backend-memfd-private,id=ram1,size=2048M,share=true -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,discard=none -machine memory-backend=ram1,kvm-type=protected -nographic -monitor pty -monitor unix:monitor,server,nowait
Mapping CTRL-C to CTRL-]
Launching VM ...

@dubek
Copy link
Member

dubek commented Jan 25, 2024

Thanks @steve-237 , it looks OK, these are the relevant qemu entries:

-cpu EPYC-v4
-smp 4
-drive if=pflash,format=raw,unit=0,file=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd,readonly
-object sev-snp-guest

This seems to match your sev-snp-measure invocation:

./sev-snp-measure.py --mode snp --vcpus=4 --vcpu-type=EPYC-v4 --ovmf=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd

Can you try to make the one-line change to sev_features as described in #32 and see if helps?

In any case, just to be sure, it would help to know exact versions (branches, commits) of host kernel, qemu, and ovmf.

@steve-237
Copy link
Author

Thanks @steve-237 , it looks OK, these are the relevant qemu entries:

-cpu EPYC-v4
-smp 4
-drive if=pflash,format=raw,unit=0,file=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd,readonly
-object sev-snp-guest

This seems to match your sev-snp-measure invocation:

./sev-snp-measure.py --mode snp --vcpus=4 --vcpu-type=EPYC-v4 --ovmf=/home/user/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd

Can you try to make the one-line change to sev_features as described in #32 and see if helps?

In any case, just to be sure, it would help to know exact versions (branches, commits) of host kernel, qemu, and ovmf.

Thank you @dubek for the suggestion.

Regarding the modification described in #32, I've reviewed the issue, but I'm unsure which specific file to modify. Could you kindly provide guidance on the exact file and location where the change should be made?

@dubek
Copy link
Member

dubek commented Jan 27, 2024

In sevsnpmeasure/vmsa.py , change line 187 to

sev_features = 0x21

@steve-237
Copy link
Author

In sevsnpmeasure/vmsa.py , change line 187 to

sev_features = 0x21

Thank you @dubek for your prompt assistance.

I've implemented the suggested modification, setting sev_features to 0x21, and I'm pleased to report that it resolved the issue. The measurement calculation now aligns with expectations.

@larrydewey
Copy link
Collaborator

New discussion occurring in #43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants