Avoiding EBUSY on TPM writes

Avoiding EBUSY on TPM writes

[Matthew Garrett]

We're running into a situation where concurrent TPM accesses can trigger 
EBUSY on write due to there either being a queued command or a response 
not yet having been read. Obviously one approach would be to retry, but 
that involves us either spinning or waiting for an arbitrary amount of 
time between attempts, which doesn't seem ideal. There's a poll 
interface that tells us whether there's a response to read but (a) that 
doesn't help in the enqueued command situation and (b) this would still 
be racy - we could be notified that the response has been read, be 
preempted, and have another process perform a write before we get the 
opportunity to.

What's the right way to fix this? One approach would simply be to 
replace the EBUSY with an interruptible sleep and wake the process when 
the TPM is available, but that feels like it's technically an ABI break.

Re: Avoiding EBUSY on TPM writes

[James Bottomley]

On Thu, 2023-06-15 at 22:09 +0100, Matthew Garrett wrote:
> We're running into a situation where concurrent TPM accesses can
> trigger EBUSY on write due to there either being a queued command or
> a response not yet having been read. Obviously one approach would be
> to retry, but  that involves us either spinning or waiting for an
> arbitrary amount of  time between attempts, which doesn't seem ideal.
> There's a poll  interface that tells us whether there's a response to
> read but (a) that  doesn't help in the enqueued command situation and
> (b) this would still  be racy - we could be notified that the
> response has been read, be  preempted, and have another process
> perform a write before we get the opportunity to.

That's by design: the fd interface is command/response per open fd, so
if you try to send another command before you get a response you'll get
an EBUSY by design.  If you didn't, how would you know which response
belonged to which command (there's no counter or other identifier)?

However, this behaviour is per-fd, why can't you just open multiple
fd's for your multiple accesses?  /dev/tpmrm0 will assure that they
don't see each other and that the commands are properly sequenced
without giving you an EBUSY.  And bonus you don't have to keep global
track of how many transient resources you've used.

James

Re: Avoiding EBUSY on TPM writes

[Matthew Garrett]

On Thu, Jun 15, 2023 at 07:38:57PM -0400, James Bottomley wrote:

> However, this behaviour is per-fd, why can't you just open multiple
> fd's for your multiple accesses?  /dev/tpmrm0 will assure that they
> don't see each other and that the commands are properly sequenced
> without giving you an EBUSY.  And bonus you don't have to keep global
> track of how many transient resources you've used.

Argh! Sorry, I'd missed that this was per-fd - that makes complete 
sense. Let me figure out why we're re-using the same fd for multiple 
requests.