Add support for compute runtime quote policy#6474
Add support for compute runtime quote policy#6474martintomazic wants to merge 10 commits intomartin/breaking/explicit-observer-modefrom
Conversation
✅ Deploy Preview for oasisprotocol-oasis-core canceled.
|
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
from
d0c991e to
859e7a8
Compare
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
from
859e7a8 to
b795a2e
Compare
| /// The compute runtime quote policy. | ||
| #[cbor(optional)] | ||
| compute_policy: sgx::QuotePolicy, |
There was a problem hiding this comment.
This field is ignored for now and only here to pass e2e test.
In practice we probably need new RHP method (similar to node identity), to signal whether compute policy should be respected or not. Technically not breaking?
The runtime should sign with its RAK whether the intention of this enclave is to be used as the one registering on the consensus (having access to keymanager) or is the intention to be used in the less constrained environments (default policy only). Similar solution to what is done for the node_id, i.e. make it part of the hash structure and sign with RAK and validate signature on the consensus side.
Do we really need this / what are possible attack vectors without it?
There was a problem hiding this comment.
I would avoid this extra verification for now as I don't see what attack this would prevent. It is other runtimes and the consensus layer that are enforcing this policy.
There was a problem hiding this comment.
Agree as long as we do 2 side verification on both enclave_rpc/consensus side (confirmed myself again) exploiting this is not possible. Moreover, currently the keymanager policy must be respected on both sides when interacting with it.
If however, at an point we change keymanager-RONL interaction, so that RONL must only satisfy its policy when querying keymanager for its secrets, we should be careful, not to accidentally use the default one, especially if we introduce remote RONLs. The problem there would be if the ROFL would want stricter policy then the default RONL, but again this would be mitigated by the enclave rpc using compute policy.
Having ROFL requiring stricter policy than the keymanager/compute nodes wouldn't make sense given it depends on them directly, so ignoring this corner case.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #6474 +/- ##
==========================================
- Coverage 64.79% 64.43% -0.36%
==========================================
Files 699 699
Lines 68206 68264 +58
==========================================
- Hits 44193 43988 -205
- Misses 18999 19205 +206
- Partials 5014 5071 +57 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| /// The compute runtime quote policy. | ||
| #[cbor(optional)] | ||
| compute_policy: sgx::QuotePolicy, |
There was a problem hiding this comment.
I would avoid this extra verification for now as I don't see what attack this would prevent. It is other runtimes and the consensus layer that are enforcing this policy.
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
3 times, most recently
from
d217ddf to
9675e14
Compare
| // ComputePolicy is additional compute runtime quote policy. | ||
| // | ||
| // If not nil, it replaces (default) Policy for the compute and observer nodes. | ||
| ComputePolicy *quote.Policy `json:"compute_policy,omitempty"` |
There was a problem hiding this comment.
Not sure if "compute policy" is the best name for this given that both policies apply to compute runtimes, just different levels of access. Any other suggestions?
There was a problem hiding this comment.
I am not 100% fond of the name either.
StrictPolicy? and useStrictPolicy to configure runtime provisioner early validation?
Cons: now is less clearer why keymanager cannot have strict policy, also strictness is not actually enforced, e.g. with current code you can actually set looser policy for the compute one (but that would be violation of the intent making this name more suitable).
HasLocalStorage variable was misleading as archive node has the local storage yet the variable was set to false for it. Long term solution is to stop abusing light history for tracking storage worker progress, by possibly following NodeDB last synced round directly.
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
from
9675e14 to
c342c74
Compare
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
from
c342c74 to
b37e6f3
Compare
See if we can trigger real quote verification. This will still get rejected at local verification instead of consensus.
martintomazic
force-pushed
the
martin/feature/compute-policy
branch
from
b37e6f3 to
7466948
Compare
martintomazic
changed the base branch from
master
to
martin/breaking/explicit-observer-mode
martintomazic
force-pushed
the
martin/breaking/explicit-observer-mode
branch
from
7904cf5 to
3a8941f
Compare
2 participants
Replaces #6471 closes #6387.