Skip to content

snp-latest: no kernel hashes table #5

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

Closed
MOZGIII opened this issue Jun 21, 2023 · 6 comments
Closed

snp-latest: no kernel hashes table #5

MOZGIII opened this issue Jun 21, 2023 · 6 comments

Comments

@MOZGIII
Copy link

MOZGIII commented Jun 21, 2023

The OVMF image that is produced by OvmfPkg/AmdSev/AmdSevX64.dsc fails to boot with VerifyBlob: Verifier called but no hashes table discoverd in MEMFD. It seems like there should be a placeholder hash table in the OVMF image somewhere that QEMU would fill in with hashes when SNP and kernel-hashes=on is selected.

Any hint as to what I'm doing wrong?

This is on snp-latest branch.


CC: @tonycdot, @dmitrylavrenov

@tlendacky
Copy link
Collaborator

Adding @dubek for input.

@dubek
Copy link

dubek commented Jun 24, 2023

The snp-latest branch of OVMF (this repo) indeed includes the support for kernel hashes for SNP. But it must work hand-in-hand with the relevant QEMU branch to use it. I see that AMD's QEMU snp-latest branch has this support ( https://github.com/AMDESE/qemu/tree/snp-latest ) -- are you using this branch of QEMU?

To further allow debugging this, please share the full command-line of QEMU.

Also, if you can, add -trace 'kvm_sev_*' to the QEMU command-line and share the trace output of QEMU as it starts the guest.

@MOZGIII
Copy link
Author

MOZGIII commented Jun 24, 2023

I am using snp-latest QEMU branch as well, yes!

Here are the arguments:

/cvm/result/host/qemu/bin/qemu-system-x86_64
-name VM
-uuid 33726BCA-4717-41C7-A333-14A292B98322
-enable-kvm
-machine q35
-m 2048M,slots=5,maxmem=30G
-smp cpus=4,maxcpus=32
-cpu EPYC-v4
-machine confidential-guest-support=sev0,memory-encryption=sev0,vmport=off
-object memory-backend-memfd-private,id=ram1,size=2048M,share=true
-object sev-snp-guest,id=sev0,policy=0x130135,cbitpos=51,reduced-phys-bits=1,discard=none,kernel-hashes=on
-machine memory-backend=ram1,kvm-type=protected
-netdev user,id=net0
-device virtio-net-pci,mac=AE:2C:22:77:E5:70,disable-legacy=on,iommu_platform=true,netdev=net0,romfile=
-drive if=pflash,format=raw,unit=0,file=/cvm/state/OVMF.fd,readonly=on
-kernel /cvm/result/guest/bzImage
-append console=ttyS0 earlyprintk=serial
-initrd /cvm/result/guest/initrd
-action panic=shutdown
-nodefaults
-nographic
-serial stdio
-chardev pty,id=mon0,mux=off,logfile=/cvm/logs/monitor.log
-mon chardev=mon0,mode=readline
-D /cvm/logs/qemu.log
  • QEMU is from the snp-latest branch:

    $ /cvm/result/host/qemu/bin/qemu-system-x86_64 --version
    QEMU emulator version 7.2.0
    Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
  • Host kernel is from the snp-host-latest branch

@MOZGIII
Copy link
Author

MOZGIII commented Jun 24, 2023

Trace:

qemu.log (looks like there's no hashes page written, as there's only one normal page)

The terminal output (qemu + serial):

out.txt

UPD: re-upload the logs from after a clean rebuild; old ones: out.txt qemu.log (no changes though)

@MOZGIII
Copy link
Author

MOZGIII commented Jun 24, 2023

Here is OVMF binary: https://drive.google.com/file/d/16bcXXzLdULlYmKm-3WPGfVKz0vO8mt2J/view?usp=sharing
I did the hex search and the GUIDs for the kernel hash table are nowhere to be found in there. This might be expected, but I don't understand the OVMF source enough to tell how it works just yet.

build-log.txt (building with nix, so some additional output surrounding the OVMF build is present, feel free to disregard it)

@MOZGIII
Copy link
Author

MOZGIII commented Jun 24, 2023

Sorry, never mind, this seems like a build issue on my end!

@MOZGIII MOZGIII closed this as completed Jun 24, 2023
mdroth pushed a commit that referenced this issue Mar 29, 2024
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4537
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4538

Bug Details:
PixieFail Bug #4
CVE-2023-45232
CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')

Infinite loop when parsing unknown options in the Destination Options
header

PixieFail Bug #5
CVE-2023-45233
CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')

Infinite loop when parsing a PadN option in the Destination Options
header

Change Overview:

Most importantly this change corrects the following incorrect math
and cleans up the code.

>   // It is a PadN option
>   //
> - Offset = (UINT8)(Offset + *(Option + Offset + 1) + 2);
> + OptDataLen = ((EFI_IP6_OPTION *)(Option + Offset))->Length;
> + Offset     = IP6_NEXT_OPTION_OFFSET (Offset, OptDataLen);

> case Ip6OptionSkip:
> - Offset = (UINT8)(Offset + *(Option + Offset + 1));
>   OptDataLen = ((EFI_IP6_OPTION *)(Option + Offset))->Length;
>   Offset     = IP6_NEXT_OPTION_OFFSET (Offset, OptDataLen);

Additionally, this change also corrects incorrect math where the calling
function was calculating the HDR EXT optionLen as a uint8 instead of a
uint16

> - OptionLen = (UINT8)((*Option + 1) * 8 - 2);
> + OptionLen = IP6_HDR_EXT_LEN (*Option) -
IP6_COMBINED_SIZE_OF_NEXT_HDR_AND_LEN;

Additionally this check adds additional logic to santize the incoming
data

Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>

Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
mdroth pushed a commit that referenced this issue Mar 19, 2025
This patch does not impact functionality. It aims to clarify the
synchronization flow between the BSP and APs to enhance code
readability and understanding:

Steps #6 and #11 are the basic synchronization requirements for all
cases.

Steps #1 is additional requirements if the MmCpuSyncModeTradition
mode is selected.

Steps #1, #2, #3, #4, #5, #7, #8, #9, and #10 are additional
requirements if the system needs to configure the MTRR.

Steps #9 and #10 are additional requirements if the system needs to
support the mSmmDebugAgentSupport.

Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
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

3 participants