search

coconut-svsm / svsm

COCONUT-SVSM
MIT License
122 stars 43 forks source link

Add test to check the pre-calculated launch measurement #392

Closed stefano-garzarella closed 2 months ago

stefano-garzarella commented 5 months ago

This PR introduces a test to check that the launch measurement pre-calculated by igvmmeasure is the same as that returned by the VMPL0 attestation report at runtime. To support that, this PR also adds a serial port (COM3) to allow the host to communicate with the test running in the VM. This could be used in the future for other tests as well.

Tested locally with:

QEMU=/path/to/coconut/qemu/build/qemu-system-x86_64 make test-in-svsm
roy-hopkins commented 4 months ago

Just taking a look at this. At the moment I'm getting a test failure due to an incorrect measurement - probably due to my environment.

stefano-garzarella commented 4 months ago

Pushed by mistake (I had to test the code on the SEV-SNP machine) and there is something wrong with the serial port locks by moving them to kernel/src/testing.rs

stefano-garzarella commented 4 months ago

Strage, if I rebase on previous commit (126400b9c2c2cf0f43ecda9b129ee45577f6b493) it works, but on current main (fa92efca6c0c3b6a872db668522385dc00449e93), the test are not executed and the output is just the Stage2:

[Stage2] COCONUT Secure Virtual Machine Service Module (SVSM) Stage 2 Loader
[Stage2] Order-00: total pages:    15 free pages:     1
[Stage2] Order-01: total pages:     0 free pages:     0
[Stage2] Order-02: total pages:     1 free pages:     1
[Stage2] Order-03: total pages:     1 free pages:     1
[Stage2] Order-04: total pages:     0 free pages:     0
[Stage2] Order-05: total pages:     0 free pages:     0
[Stage2] Total memory: 108KiB free memory: 52KiB
[Stage2]   kernel_region_phys_start = 0x0000008000000000
[Stage2]   kernel_region_phys_end   = 0x0000008001000000
[Stage2]   kernel_virtual_base   = 0xffffff8000000000

This happen only with the last patch of this PR applied. Any idea?

stefano-garzarella commented 4 months ago

On current main, this PR works only if I revert commit 683ce9566471625175c794d4df38a67eeed34650 and 79c18d662397fa0a5be2e10cea7155e1e396253e , but I'm not sure if they are related.

Without reverting them, SVSM is not starting and all the tests are not executed. Ideas or suggestions on how to debug? @roy-hopkins @00xc

00xc commented 4 months ago

Interesting, when I run in-SVSM tests on your branch I get the following:

[SVSM] test greq::pld_report::tests::test_ecdsa_p384_sha384_signature_offsets ...
[SVSM] test greq::pld_report::tests::test_snp_report_request_offsets ...
[SVSM] test greq::pld_report::tests::test_snp_report_response_offsets ...
[SVSM] test greq::services::tests::test_snp_launch_measurement ...
[SVSM] ERROR: Panic: CPU[0] panicked at kernel/src/greq/services.rs:137:9:
assertion `left == right` failed
  left: [204, 126, 175, 255, 231, 55, 151, 54, 177, 236, 0, 166, 142, 10, 234, 39, 153, 46, 210, 245, 52, 168, 212, 128, 10, 166, 62, 87, 28, 45, 49, 82, 146, 129, 80, 12, 185, 94, 82, 58, 16, 248, 208, 72, 200, 24, 252, 208]
 right: [234, 244, 164, 113, 111, 124, 171, 218, 152, 54, 231, 36, 150, 137, 51, 7, 22, 58, 202, 168, 149, 134, 254, 136, 100, 43, 182, 202, 16, 192, 223, 85, 152, 218, 40, 209, 239, 169, 45, 90, 201, 173, 204, 254, 253, 14, 139, 38]
[SVSM] ---BACKTRACE---:
[SVSM]   [0xffffff80000f17ee]
[SVSM]   [0xffffff8000030d0d]
[SVSM]   [0xffffff800003d33e]
[SVSM]   [0xffffff800009dc61]
[SVSM]   [0xffffff800002b1c1]
[SVSM]   [0xffffff80000313a1]
[SVSM]   [0xffffff80000c8cb5]
[SVSM]   [0xffffff80000c4d5b]
[SVSM]   Invalid frame
[SVSM] ---END---

The output is very similar in release mode.

stefano-garzarella commented 4 months ago

@00xc just to be sure, commit a9469eab5150a719e603b53b5fc5c2c4ced0ddcb ?

Now that you mention I tried to run the in-SVSM tests in release mode, and it worked (all tests passed included the new one), while in debug I still have https://github.com/coconut-svsm/svsm/pull/392#issuecomment-2221010020

stefano-garzarella commented 4 months ago

BTW the mismatch could be related to the host kernel, (e.g. debug_swap kernel parameter). Do you have some param enabled or a different kernel in the host? (I'm using commit bc4de28e0cc1e7cf404af311c4052560aba355ba from coconut's linux)

00xc commented 4 months ago

@00xc just to be sure, commit a9469ea ?

Yep.

Now that you mention I tried to run the in-SVSM tests in release mode, and it worked (all tests passed included the new one), while in debug I still have #392 (comment)

It works for me in both modes.

However, I noticed that we do the following when booting with IGVM:

https://github.com/coconut-svsm/svsm/blob/fa92efca6c0c3b6a872db668522385dc00449e93/Makefile#L77

The important part being --comport 3, which results in setting I/O port 0x3e8 (COM3) as the debug port. I noticed that you also use this port in your implementation. Could it be that test I/O and console I/O are interfering with each other?

Note that using qemu's fw_cfg instead uses port 0x3f8 (COM1).

stefano-garzarella commented 4 months ago

I just did rustup update:

   stable-x86_64-unknown-linux-gnu updated - rustc 1.79.0 (129f3b996 2024-06-10) (from rustc 1.78.0 (9b00956e5 2024-04-29))
  nightly-x86_64-unknown-linux-gnu updated - rustc 1.81.0-nightly (0c81f94b9 2024-07-10) (from rustc 1.80.0-nightly (8387315ab 2024-05-14))

And now it's working also here, but now I'm not sure if we have some hidden issue.

stefano-garzarella commented 4 months ago

However, I noticed that we do the following when booting with IGVM:

https://github.com/coconut-svsm/svsm/blob/fa92efca6c0c3b6a872db668522385dc00449e93/Makefile#L77

The important part being --comport 3, which results in setting I/O port 0x3e8 (COM3) as the debug port. I noticed that you also use this port in your implementation. Could it be that test I/O and console I/O are interfering with each other?

ehm, why we are setting --comport 3 ?

Note that using qemu's fw_cfg instead uses port 0x3f8 (COM1).

Without this PR, in scripts/test-in-svsm.sh we don't set the backend form COM3, so I'm not sure SVSM is really using it.

Should I use COM4?

stefano-garzarella commented 4 months ago

Oh wait, --comport 3 is only for bin/coconut-hyperv.igvm, for QEMU we are using the default (1).

00xc commented 4 months ago

Oh wait, --comport 3 is only for bin/coconut-hyperv.igvm, for QEMU we are using the default (1).

Yes, that's what I meant :)

00xc commented 4 months ago

Should I use COM4?

Yes, please try using a different port for tests.

stefano-garzarella commented 4 months ago

Should I use COM4?

Yes, please try using a different port for tests.

Okay, I'll do.

About the test failure in your env, can you check this:

BTW the mismatch could be related to the host kernel, (e.g. debug_swap kernel parameter). Do you have some param enabled or a different kernel in the host? (I'm using commit bc4de28e0cc1e7cf404af311c4052560aba355ba from coconut's linux)

stefano-garzarella commented 4 months ago

v3:

v2:

00xc commented 4 months ago

BTW the mismatch could be related to the host kernel, (e.g. debug_swap kernel parameter). Do you have some param enabled or a different kernel in the host? (I'm using commit bc4de28e0cc1e7cf404af311c4052560aba355ba from coconut's linux)

There is no such parameter in the cmdline. I'm not sure which host version we have, as it is an internal machine on which I did not install the kernel. uname says "6.8.1-1-coco".

roy-hopkins commented 4 months ago

Apologies for the delay in joining this thread - I was away.

There is no such parameter in the cmdline. I'm not sure which host version we have, as it is an internal machine on which I did not install the kernel. uname says "6.8.1-1-coco".

I've just checked on that same machine - the 6.8.1-1-coco kernel has DEBUG_SWAP disabled which should match the IGVM file that is generated but I also see a mismatch in the attestation report. I can confirm however that your latest branch works on my SEV-SNP system for both debug and release builds and the attestation measurement matches.

stefano-garzarella commented 4 months ago

v4:

stefano-garzarella commented 4 months ago

@00xc about the problem you were seeing on your machine, could it be related to https://github.com/coconut-svsm/svsm/issues/433 ?

Should we merge this PR to discover that issues?

joergroedel commented 3 months ago

I am also running in a measurement mismatch error, debug_swap is off on my machine. The machine has a Milan CPU, any hints on what might be wrong?

Freax13 commented 3 months ago

This works for me. Tested on EPYC Milan. I'm using the latest KVM and QEMU patches mentioned in the docs.

joergroedel commented 3 months ago

@stefano-garzarella Can you please downgrade a measurement mismatch from a fatal error to a warning? With that the PR is ready to merge and we can move on fixing the causes of the mismatches.

stefano-garzarella commented 3 months ago

v5:

stefano-garzarella commented 3 months ago

I am also running in a measurement mismatch error, debug_swap is off on my machine. The machine has a Milan CPU, any hints on what might be wrong?

What kernel is running your host?

@stefano-garzarella Can you please downgrade a measurement mismatch from a fatal error to a warning? With that the PR is ready to merge and we can move on fixing the causes of the mismatches.

@joergroedel done ;-)

stefano-garzarella commented 2 months ago

@00xc @joergroedel I think I addressed all the comments, can we merge this?