Conversation
…hit up intel when testing
| use tracing::debug; | ||
|
|
||
| /// For fetching collateral directly from Intel | ||
| pub const PCS_URL: &str = "https://api.trustedservices.intel.com"; |
There was a problem hiding this comment.
question:
should this be pre-parsed (lazily?) url::URL? to avoid re-parsing it all the time.
| #[derive(Clone)] | ||
| pub struct Pccs { | ||
| /// The URL of the service used to fetch collateral (PCS / PCCS) | ||
| pccs_url: String, |
There was a problem hiding this comment.
suggestion:
| pccs_url: String, | |
| url: String, |
^-- the struct is already Pccs, no need to repeat that prefix.
|
|
||
| impl Pccs { | ||
| /// Creates a new PCCS cache using the provided URL or Intel PCS default | ||
| pub fn new(pccs_url: Option<String>) -> Self { |
There was a problem hiding this comment.
question:
maybe use builder pattern here?
| .trim_end_matches("/sgx/certification/v4") | ||
| .trim_end_matches("/tdx/certification/v4") |
There was a problem hiding this comment.
question:
why do we need this?
| let sleep_secs = refresh_sleep_seconds(next_update, now); | ||
| sleep(Duration::from_secs(sleep_secs)).await; | ||
|
|
||
| // Re-check the entry after waking in case annother task updated it |
There was a problem hiding this comment.
| // Re-check the entry after waking in case annother task updated it | |
| // Re-check the entry after waking in case another task updated it |
| tokio::spawn(async move { | ||
| let outcome = pccs_for_prewarm.startup_prewarm_all_tdx().await; | ||
| pccs_for_prewarm.finish_prewarm(outcome); | ||
| }); |
There was a problem hiding this comment.
quesetion:
what happens if we are not in tokio runtime?
| /// Resolves when cache is pre-warmed with all available collateral | ||
| pub async fn ready(&self) -> Result<PrewarmSummary, PccsError> { | ||
| let mut outcome_rx = self.prewarm_outcome_tx.subscribe(); | ||
| loop { |
There was a problem hiding this comment.
question:
can it happen that startup_prewarm_all_tdx panics (or gets aborted somehow)?
if "yes" then ready() can get stuck forever, right?
| rustls = { version = "0.23.37", default-features = false, features = ["brotli"] } | ||
| tokio = { version = "1.50.0", features = ["default"] } | ||
| tokio-rustls = { version = "0.26.4", default-features = false } | ||
| dcap-qvl = { git = "https://github.com/Phala-Network/dcap-qvl.git" } |
There was a problem hiding this comment.
question:
should we pin this to some tag/sha?
| } | ||
|
|
||
| /// Extracts the earliest next update timestamp from collateral metadata | ||
| fn extract_next_update(collateral: &QuoteCollateralV3, now: i64) -> Result<i64, PccsError> { |
There was a problem hiding this comment.
question:
should we also check for revocations at *_crl fields?
2 participants
Adds an internal Provisioning Certifcate Cache Service (PCCS) crate which pre-fetches collateral and pre-emptively refreshes it, with the goal of keeping colleteral fetching out of the hot path when verifying attestations.
This copies the functionality from theses PRs to attested-tls-proxy:
API Routes used internally
Here are the routes hit during initial caching - documented in Intel PCCS spec:
GET
https://api.trustedservices.intel.com/sgx/certification/v4/fmspcsSource: src/lib.rs:268
dcap_qvl::collateral::get_collateral_for_fmspcfor each, with both 'processor' and 'platform' as the 'ca' arguement.GET
https://api.trustedservices.intel.com/sgx/certification/v4/pckcrl?ca={processor|platform}&encoding=derSource builder: url_pckcrl():69
GET
https://api.trustedservices.intel.com/tdx/certification/v4/tcb?fmspc={FMSPC}Source builder: url_tcb():77
GET
https://api.trustedservices.intel.com/tdx/certification/v4/qe/identity?update=standardSource builder: url_qe_identity():81
- This gets the identity of the quoting enclave
Example demonstrating pre-warm
Included with the
pccscrate is an example which demonstrate the warm-up cache filling using the Intel PCS.Here is an example output which shows which FMSPCs end up in the cache and which are rejected as being not relevant for TDX quote verification:
Show output revealing which FMSPCs are cached
Possible optimisation
It takes quite a while. We could drastically reduce the number of API calls in the warm-up, as many are not FMSPC dependent and are made redundantly. But this would comes at the cost of rolling more of this ourselves and having less code maintained by Phala.
Show breakdown of how many API calls we could save
Assumingg:
Right now, each of those 74 attempts triggers these PCS calls:
Plus the initial:
So current PCS call count is roughly:
If you cache the shared routes during prewarm:
That becomes:
So the saving is: