Skip to content
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

Merged
merged 39 commits into from
Jan 26, 2023
Merged

Collateral handling for DCAP #1134

merged 39 commits into from
Jan 26, 2023

Conversation

Niederb
Copy link
Contributor

@Niederb Niederb commented Jan 3, 2023

This PR contains a lot of boilerplate code for handling the collateral data:

  • Getting the collateral data from SGX
  • Converting the C data structure into something more rust like
  • Sending the collateral to the chain via extrinsics
  • Next step would be something like Collateral updater component #1104
  • DCAP is still de-activated and the pallet is not ready yet anyway, but I think it is ready for a first review

Copy link
Contributor

@OverOrion OverOrion left a 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.

core-primitives/attestation-handler/src/collateral.rs Outdated Show resolved Hide resolved
enclave-runtime/src/attestation.rs Outdated Show resolved Hide resolved
enclave-runtime/src/attestation.rs Show resolved Hide resolved
core-primitives/enclave-api/src/remote_attestation.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@clangenb clangenb left a 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.

core-primitives/attestation-handler/src/collateral.rs Outdated Show resolved Hide resolved
core-primitives/attestation-handler/src/collateral.rs Outdated Show resolved Hide resolved
core-primitives/enclave-api/src/remote_attestation.rs Outdated Show resolved Hide resolved
core-primitives/utils/src/hex.rs Show resolved Hide resolved
service/src/account_funding.rs Show resolved Hide resolved
service/src/main.rs Show resolved Hide resolved
service/src/main.rs Show resolved Hide resolved
Copy link
Contributor

@clangenb clangenb left a 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!

service/src/main.rs Show resolved Hide resolved
Comment on lines 115 to 116
let json = String::from_utf8_lossy(data);
let value: serde_json::Value = serde_json::from_str(&json).ok()?;
Copy link
Contributor

@OverOrion OverOrion Jan 23, 2023

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:

Suggested change
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()?;

Copy link
Contributor

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?

Copy link
Contributor

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, because SgxQlQveCollateral is the Rust version of sgx_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, because I 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!

Copy link
Contributor

@clangenb clangenb Jan 23, 2023

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")

Copy link
Contributor

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.

Copy link
Contributor Author

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()?;

Copy link
Contributor Author

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.

Copy link
Contributor

@OverOrion OverOrion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

@Niederb Niederb marked this pull request as ready for review January 26, 2023 06:35
@Niederb Niederb added A0-core Affects a core part B1-releasenotes C1-low 📌 Does not elevate a release containing this beyond "low priority" E3-hardmerge PR introduces a lot changes in a lot of files. Requires some effort to merge or rebase to. labels Jan 26, 2023
@Niederb Niederb self-assigned this Jan 26, 2023
@clangenb clangenb merged commit 39624bc into master Jan 26, 2023
m-yahya pushed a commit to olisystems/BEST-Energy that referenced this pull request Feb 17, 2023
* 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>
@clangenb clangenb deleted the tn/collateral-handling branch February 20, 2023 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A0-core Affects a core part B1-releasenotes C1-low 📌 Does not elevate a release containing this beyond "low priority" E3-hardmerge PR introduces a lot changes in a lot of files. Requires some effort to merge or rebase to.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants