-
Notifications
You must be signed in to change notification settings - Fork 47
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
Implement the attestation report feature #69
Conversation
026947d
to
009c8ab
Compare
Hi @stefano-garzarella and @00xc, thank you very much for the feedback. I applied the changes below and marked their threads as resolved.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still need to study the details, so I may come back with new comments, but for now LGTM, I left just a minor comment.
Some new features may require increasing the stack size: coconut-svsm#69 (comment) To avoid problems when the gdb stub is enabled, it is best to define STACK_PAGES as a constant plus extra pages depending on the features (e.g. STACK_PAGES_GDB). This way we have a single point to modify for the base of STACK_PAGES. No functional changes. Signed-off-by: Stefano Garzarella <[email protected]>
009c8ab
to
478be10
Compare
|
478be10
to
16f24aa
Compare
|
16f24aa
to
fed388e
Compare
Hi everyone, I updated the branch and it's much better now.
|
FYI main branch should have that fixed with 7236a1a |
Except for the missing Drop trait implementations this LGTM. |
fed388e
to
3162668
Compare
3162668
to
3bb2cf4
Compare
3bb2cf4
to
1abd100
Compare
Thanks @crobinso @daaltobe @roy-hopkins @deeglaze and @joergroedel for the feedback! attestation-report and attestation-report-test branches updated (v5):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left two comments.
$ make V=1 or $ make V=2 These can be used to easily build targets in verbose mode. That can be helpful for debugging. Currently we support V=1 or V=2 (the biggest is the most verbose). Signed-off-by: Claudio Carvalho <[email protected]>
Both functions are used to send SNP_GUEST_REQUEST messages to the PSP, but the guest_ext_request() includes an extended request to the hypervisor. More information can be found in the AMD GHCB specification. Signed-off-by: Claudio Carvalho <[email protected]>
Export the VMPCK size to be used in other crates. Signed-off-by: Claudio Carvalho <[email protected]>
Add a generic interface for AES-256 GCM encryption and decryption. They are both required for requesting an attestation report. With this interface we should be able to keep the crypto code isolated in crates and also easily choose which crypto implementation should be compiled-in. Signed-off-by: Claudio Carvalho <[email protected]>
afd7c4b
to
30c556e
Compare
Thanks @Freax13 and @joergroedel for the feedback. In the last branch update (v6 - from afd7c4b to 30c556e), I addressed all the changes you suggested.
The test branch was also updated accordingly. |
// The sequence number is restored only when the guest is rebooted. | ||
let Some(msg_seqno) = self.seqno_last_used().checked_add(1) else { | ||
log::error!("SNP_GUEST_REQUEST: sequence number overflow"); | ||
disable_vmpck0(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We call disable_vmpck0
for a bunch of error cases. Have you considered additionally calling disable_vmpck0
in the SVSM's panic handler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although we call disable_vmpck0
for multiple error cases, they are very specific and they not necessarily cause panic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'm not saying that they cause a panic. I'm just saying that if some other code in the SVSM panicked (e.g. because an attacker is trying to exploit the SVSM), the SVSM's state might be messed up, so we might also also consider erasing the keys to prevent exploits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'm not saying that they cause a panic. I'm just saying that if some other code in the SVSM panicked (e.g. because an attacker is trying to exploit the SVSM), the SVSM's state might be messed up, so we might also also consider erasing the keys to prevent exploits.
Oh, got it! I will call disable_vmpck0
from the panic handler too. Thanks
Add a RustCrypto-based implementation for the SVSM Aes256GCM trait. Signed-off-by: Claudio Carvalho <[email protected]>
ef7a7ff
to
817c317
Compare
Thanks @Freax13 for the feedback. All changes applied.
|
Hi @cclaudio, the current state of this PR seems to end up in a deadlock for me, GDB session:
|
Hi @osteffenrh, thanks for the feedback. The PR seems to be working for me with and without
|
Hi @osteffenrh, I suspect the hang on the lock is due to the fact that the GDB stub borrows the same functions as the code it is debugging, often resulting in deadlocks if you try to single step over lock code. You can try setting breakpoints instead after the lock has been taken. That normally works. Having said that, I tried running the latest code from this PR this morning, albeit merged into my own development branch. I found that it was hanging on the call to |
Informing the hypervisor about the encryption state change also seems to fix #69 (comment) for me. |
// The sequence number is restored only when the guest is rebooted. | ||
let Some(msg_seqno) = self.seqno_last_used().checked_add(1) else { | ||
log::error!("SNP_GUEST_REQUEST: sequence number overflow"); | ||
disable_vmpck0(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'm not saying that they cause a panic. I'm just saying that if some other code in the SVSM panicked (e.g. because an attacker is trying to exploit the SVSM), the SVSM's state might be messed up, so we might also also consider erasing the keys to prevent exploits.
These structures are used in the SNP_GUEST_REQUEST communication between the guest and the PSP; their implementation follow the AMD SEV-SNP specification, chapter 7. The SnpGuestRequestMsg is used to carry a SNP_GUEST_REQUEST command or response in the payload, which is encrypted using AES-256 GCM. This message can't be tampered with by the hypervisor because only the PSP and the guest have access to the key to decrypt the payload. An extended SNP_GUEST_REQUEST command also requests data from the hypervisor; in this case, the SnpGuestRequestExtData is also provided. The hypervisor will use it to store the requested data. Signed-off-by: Claudio Carvalho <[email protected]>
Add a driver to send SNP_GUEST_REQUEST commands to the PSP. The command can be any of the request or response command types defined in the SEV-SNP spec, regardless if it's a regular or an extended command. The send_regular_guest_request() and send_extended_guest_request() functions can be used to send regular and extended commands, respectively. guest_request_driver_init() is used to initialize the static driver instance. Signed-off-by: Claudio Carvalho <[email protected]>
The panic handler is called when the SVSM state is not reliable any more. Disable the VMPCK0 key to prevent it from being exploited. Signed-off-by: Claudio Carvalho <[email protected]>
Add get_regular_report() and get_extended_report(). They both call the SNP_GUEST_REQUEST driver to request a VMPL0 attestation report, the difference is that get_extended_report() also requests the SEV-SNP certificates needed to verify the attestation report. The get_extended_report() function will return an empty buffer if the SEV-SNP certificates where not imported yet, but they can be imported from the host using the github virtee/snphost project: $ snphost import <PEM-files-directory> For testing purposes, if you import PEM files that contain some random data, you should be able to see the same random data when you call get_extended_report() from the SVSM. Signed-off-by: Claudio Carvalho <[email protected]>
817c317
to
fffd826
Compare
Thanks @osteffenrh @roy-hopkins @Freax13 @tlendacky for the feedback. Changes included in this branch update:
|
Merged manually, thanks. Any pending feedback can be addressed on-top. |
This PR implements the attestation report feature discussed in the issue #67
make test
will test the main functions used to encrypt and decrypt messages.The branch attestation-report-test can be used to test the
get_report()
andget_ext_report()
functions. It contains one extra patch that calls them at boot time and print some information in the log.