On 4/21/22 12:04 AM, Isaku Yamahata wrote:
On Tue, Apr 19, 2022 at 06:26:43PM -0700,
Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> wrote:
On 4/19/22 6:20 PM, Isaku Yamahata wrote:
If timeout occurs, the state of adev->tdquote_buf is unknown. It's not safe
to continue to using adev->tdquote_buf. VMM would continue to processing
getquote request with this buffer. What if TDX_CMD_GEN_QUOTE is issued again,
and tdquote_buf is re-used?
This part is not clearly discussed in the specification. May be spec
should define some reasonable timeout and teardown details.
Regarding not using this buffer again, what happens if we de-allocate
it on timeout and the host still updates it?
Until GET_QUOTE_IN_FLIGHT is cleared, the shared page is owned by VMM, TD
attestation driver shouldn't reuse/free the pages.
In the case of this driver, I think of two options
- don't timeout. wait for interrupt to arrive and check the shared GPA state.
- allow timeout. When the next request comes, check the shared GPA state.
If it's still GET_QUOTE_IN_FLIGHT, return EBUSY.
Out of the above two options, I think option 1 is better. It is simpler
to serialize them using mutex compared to checking the shared buffer of
previous request.
It's possible for VMM to keep the shared GPA forever maliciously(DoS) or
unintentionally due to bug. TD can't do much about it.
I will add a note about it in commit log.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
