-
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
Collateral handling for DCAP #1134
Conversation
35a789e
to
78e1fcf
Compare
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.
Overall a nice job, I had some remarks, will check some parts more thoroughly (mostly the unsafe parts) the next time.
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.
Thanks a lot, it looks very clean to me! I have some minor questions, but otherwise I am highly satisfied.
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.
Thanks for the fixes, looks good to me now!
let json = String::from_utf8_lossy(data); | ||
let value: serde_json::Value = serde_json::from_str(&json).ok()?; |
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.
On the call site data is often a C terminated string, and I encountered an issue, where the terminating \0
was still there and serde failed with unexpected ending character (a simple println!()
did not show it, it needed to be debug formatted).
For this reason I suggest this:
let json = String::from_utf8_lossy(data); | |
let value: serde_json::Value = serde_json::from_str(&json).ok()?; | |
let json = CStr::from_bytes_with_nul(data) | |
.expect("CStr::from_bytes_with_nul failed") | |
.to_str() | |
.expect("Must not contain invalid UTF-8 data"); | |
let value: serde_json::Value = serde_json::from_str(&json).ok()?; |
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.
Can you explain, why it is safe to put an expect here instead of returning an error?
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.
Of course:
from_bytes_with_nul().expect()
is safe, becauseSgxQlQveCollateral
is the Rust version ofsgx_ql_qve_collateral_t
, which states the following:/** This is the data provided to the quote verifier by the verifying platform software. They are NULL terminated strings. [...] */
to_str().expect()
is safe, becauseI could not find an explicit guarantee regarding the fields always being valid UTF-8 sequences. -> The second.expect()
should be.ok()?
instead, right?
Nice catch @clangenb, sorry for assuming too much!
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.
Thanks for the explanation. However, I am still unsure. We must never panic in the enclave, as this might leak sensitive data. So I prefer that the function doesn't assume that it is called in the correct context. I prefer to be defensive here and also handle the error case. In general, I only allow expect
, when the context is static, and it does really not allow panics. Then we can do something like: expect("does not overflow because of this check above blabla: qed")
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.
Thank you for the clarifications, absolutely understandable, then returning the error is the way to go.
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.
CStr::from_bytes_with_nul(..)
fails if the null terminator is missing. In order to keep it more general I would suggest the following solution:
let json = String::from_utf8_lossy(data);
// Remove potential C-style null terminators
let json = json.trim_matches(char::from(0));
let value: serde_json::Value = serde_json::from_str(json).ok()?;
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.
Alright, I pushed the changes.
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.
LGTM, thank you!
Co-authored-by: Szilárd Parrag <szilard.parrag@gmail.com>
Co-authored-by: Szilárd Parrag <szilard.parrag@gmail.com>
d2e4fb1
to
90c466d
Compare
* First version that manages to register a quoting enclave * Move collateral to attestation-handler * Work on collateral handling * Use the real collateral data for quoting enclave * Make the dump-ra CLI command work * Work towards register_tcb_info * Add all the boilerplate code to register TCB info * Reduce code duplication for extrinsic encoding * Reduce code duplication for extrinsic sending * Extract method for collateral * Remove duplicated code * Fix clippy issues * Fix compilation error in teeracle * Return certificate and dcap quote * Cleanup * Switch to updated docker image * Disable DCAP for now * Register collateral only for DCAP * Register collateral only for DCAP * Cleanup * Update core-primitives/attestation-handler/src/attestation_handler.rs Co-authored-by: Szilárd Parrag <szilard.parrag@gmail.com> * Update enclave-runtime/src/attestation.rs Co-authored-by: Szilárd Parrag <szilard.parrag@gmail.com> * Extract shared logic into separate method * Improve documentation * Extract DCAP logic into separate function * Get rid of two unwrap() calls * Move getting the call_ids into the shared function * Use the correct Error for metadata * Add type alias for Fmspc * Improve separate_json_data_and_signature and add unit test * Fix clippy issues * Incorporate review feedback * Fix unsafe * Switch implementation of separate_json_data_and_signature * Make clippy happy * Add missing `use` * Add missing feature `preserve_order` to `serde_json_sgx` * Add compiler flag for std case * Make separate_json_data_and_signature robust to potential C-style null terminators Co-authored-by: Szilárd Parrag <szilard.parrag@gmail.com>
This PR contains a lot of boilerplate code for handling the collateral data: