Race condition with Attestors?

[hu55a1n1]

Summary

If so, what happens if some other thread also writes to /dev/attestation/user_report_data before we read from /dev/attestation/quote?

Originally posted by @thanethomson in #139 (comment)

[hu55a1n1]

So, whatever is written to /dev/attestation/user_report_data is included (and attested to) in the quote read from /dev/attestation/quote (see REPORTDATA in https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf). What could happen in theory is we could have an attestation created by a thread that is attesting to the report data from a different thread. Not sure if gramine provides any protection against this.
And gramine does allow you to have multiple threads (using sgx.max_threads in the manifest) although we're using the single-threaded runtime for tokio. So this doesn't seem to be a problem for now but definitely something to keep in mind.

Originally posted by @hu55a1n1 in #139 (comment)

[hu55a1n1]

cc: @amiller

[thanethomson]

Seems like a simple solution here, to be on the safe side, would be to deliberately serialize all attestation requests coming into the enclave?

[amiller]

This is a good point, i'm pretty sure this attestation flow is indeed not threadsafe. I would guess a lot of handling of sensitive data would need to be revisited if switching to use multiple threads

[dangush]

what's the status on this?

[hu55a1n1]

I think this isn't a major problem now because we're using tokio's single-threaded runtime. So this is something we should revisit post v0.1.