-
Notifications
You must be signed in to change notification settings - Fork 74
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
SNP Attestation #108
SNP Attestation #108
Conversation
So far is looking really good, minor details aside. Do you want a full review now or should we wait until this PR is no longer a draft? |
@slp I don't suppose a full review is necessary yet. I'm fine with your comment, and just wanted to gauge your initial thoughts. Thanks! |
86f5ed5
to
a7ac571
Compare
7290354
to
401ed7e
Compare
401ed7e
to
908d172
Compare
@slp This is ready for full review. |
908d172
to
83af19c
Compare
return NULL; | ||
} | ||
|
||
if (mount("securityfs", "/sfs", "securityfs", |
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 still need this code for SEV/SEV-ES. After opening krun-sev.json
, we need to check the "tee" field and either use this code or, for the SNP case, use the new one.
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.
Fixed in dcd5828
init/tee/kbs/kbs_curl.c
Outdated
static int | ||
KBS_CURL_ERR(char *errmsg) | ||
{ | ||
printf("ERROR (kbs_curl_post): %s\n", errmsg); |
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'm not entirely sure this function is useful. We're losing the ability to pass format strings (varargs) and it's used from more places than kbs_curl_post
, so the function name is confusing.
Probably a macro that uses __func__
to print the function name and supports passing varargs to printf
would work better.
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.
Fixed in 28e1566
init/tee/kbs/kbs_types.c
Outdated
|
||
kbs_attestation_marshal_tee_pubkey(json, mod, exp); | ||
|
||
sprintf(buf, "\"tee-evidence\":\"{\\\"report\\\":\\\"{"); |
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.
Is it worth marshaling the entire report into JSON? Seems quite expensive to me when compared to, for instance, treating the entire report as a binary blob, encoding it in an hexadecimal string and sending it to the Attestation Server. Then the AS can decode the hexadecimal string into a [u8]
array, and transmute it into a sev::firmware::guest::types::AttestationReport
.
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.
Hex encoded in b01b723
init/tee/snp_attest.h
Outdated
|
||
/* | ||
* SNP attestation report structure. Based off of the attestation report | ||
* structure described in firmware version 1.51. |
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.
Is there any chance they've changed this struct again in 1.52
? I had to put a 32 bit padding before report_data
to align properly its contents.
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.
Fixed in b01b723
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 see some really nice work here. I've tested and works fine, except for the problem with the snp_report
misalignment and the measurement comparison (I suspect we might need to update the vmsa blob too).
In addition to the comments in the code, I'd also suggest that, for consistency with init.c
, please use tabs instead of spaces and always use curly braces even when the conditional has a single statement (we should also put a coding style somewhere).
@slp Another note. I'll be removing the certificate code and modifying |
sprintf(buf, "\\\\\\\"plat_info\\\\\\\":%lu,", report->platform_info); | ||
OPENSSL_buf2hexstr_ex(report_hexstr, 0x1000, &report_hexstr_len, | ||
(unsigned char *) report, sizeof(*report), '\0'); | ||
report_hexstr[report_hexstr_len] = '\0'; |
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.
TODO
: Is this required? Or does OpenSSL null-terminate the string?
@slp Can you re-review? I've added changes fixing all of your original concerns. |
I've been testing this and it's working great after fixing the SNP measurement generation in libkrunfw. I've also confirmed still works fine with SEV/SEV-ES. Could you please rebase so we can merge it? |
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
For SNP, we don't care much for krun_set_tee_config(), as the attestation is done from the guest. Instead, wrtie the TEE config file to the data disk and allow the guest to read it from the init binary. Also including an example TEE config disk image "snp-config-data-disk.img" with the workload ID "test" and attestation URL of localhost to allow for a user to test the attestation functionality. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
With the updates allowing a TEE example to submit an disk image containing a TEE config file, we can now mount the image and read the TEE config in the init binary. We do this (and parse the TEE config) for the workload ID and attestation URL of the guest. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
The initial phase of a KBS attestation is the CHALLENGE. The CHALLENGE serves as the function that an attestation server uses to generate an ephermal nonce and send it back to the client for inclusion in the SNP attestation report. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Given the nonce from the attestation server (KBS CHALLENGE), include this nonce in the attestation and retrieve an attestation report. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
The TEE public key is used for validating a guest's attestation report with the attestation server. The attestation's response will eventually be encrypted with this public key, so only the guest will be able to decrypt the message. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
In the ATTESTATION phase, the guest will marshal of its input data (SNP attestation report, certificate chain, etc..) and send it to the KBS attestation server to attest the workload. If there is no error reported for this step, a client can assume that the attestation was successful. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
A JSON string is returned from the attestation server (specifically, a JSON string of a kbs_types::Challenge). Parse this struct to read the string value of the nonce. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
…ssphrase Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
With firmware update 1.52, the firmware required extra padding bits to align properly. Furthermore, instead of traversing each field and writing it out to the JSON buffer, use OpenSSL to hex encode the report before sending to the attestation server. Due to the fact that we now submit the SNP generation (which allows the attestation server to retrieve the certificate chain), we don't need to send the certificate chain to the attestation server from libkrun. Thus, only grab the report using SNP_GET_REPORT instead of SNP_GET_EXT_REPORT. Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
@slp Rebased :) thanks! |
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
No description provided.