-
Notifications
You must be signed in to change notification settings - Fork 152
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
Change from passing verifier to passing measurements #3375
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
1ccb67c
to
196a0ec
Compare
196a0ec
to
21f3ded
Compare
I find it a little funky that we pass |
I feel like it might be simpler to pass just |
|
I see, I got confused and thought it was this: mobilecoin/attest/verifier/config/src/lib.rs Line 114 in 2eb944a
|
I think one concern i have with passing sets of measurements around is that different advisories may apply to them but there will be no way to express that in the api. Part of the motivation for the attest verifier config crate |
Misclick sorry |
Part of the motivation for the attest verifier config crate was that SW hardening advisories may be fixed in newer enclave versions but not in historical ones, so apis that just pass lists of measurements around without tracking that are kind of fucked -- there's no way to capture that. I know that's the status quo right now, but James blocked earlier PRs that i made that were along the lines of what you are doing now |
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.
Lets pass TrustedMeasurementSet or a list of StatusVerifierConfig or something that associates hardening advisories to individual MRENCLAVE etc.
It may be a naming thing with with the ambiguity of "measurement"
pub struct TrustedMrEnclaveMeasurement {
/// The MRENCLAVE measurement
///
/// For JSON this will be hex-encoded bytes.
#[serde(with = "hex", rename = "MRENCLAVE")]
mr_enclave: [u8; 32],
/// The list of config advisories that are known to be mitigated in
/// software at this enclave revision.
#[serde(default)]
mitigated_config_advisories: Vec<String>,
/// The list of hardening advisories that are known to be mitigated in
/// software at this enclave revision.
#[serde(default)]
mitigated_hardening_advisories: Vec<String>,
} |
Okay, i get it now, thanks |
I wonder what a good name would for these |
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.
Gonna go drink my coffee 😮💨 😁☕
bb606ce
to
732810a
Compare
21f3ded
to
96ec7cd
Compare
96ec7cd
to
f645f08
Compare
❌ Heads up, I tried building android-bindings using this branch and it failed. |
❌ Heads up, I tried building full-service using this branch and it failed. |
Previously many interfaces that wished to attest to an enclave would create and pass a verifier down to the logic that would eventually try and verify the enclave's report. Now these interfaces pass in a `Vec<TrustedMeasurement>` with all of the measurements they wish to verify against. This isolates the logic for how an enclave report is verified to support different verification methods based on EPID vs DCAP.
f645f08
to
05d6a28
Compare
Kicking for re-review since I was waiting for the |
The debug messages specifying the MRSIGNER identities now say which enclave they are for.
Previously many interfaces that wished to attest to an enclave would
create and pass a verifier down to the logic that would eventually try
and verify the enclave's report.
Now these interfaces pass in a
Vec<TrustedMeasurement>
with all of themeasurements they wish to verify against. This isolates the logic for
how an enclave report is verified to support different verification
methods based on EPID vs DCAP.