linux-kernel - Re: [PATCH] tpm: sleep at least <...> ms in tpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 May 2022 17:37:40 -0400
From:   Ken Goldman <kgold@...ux.ibm.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Nayna <nayna@...ux.vnet.ibm.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Johannes Holland <johannes.holland@...ineon.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org, peterhuewe@....de, jgg@...pe.ca
Subject: Re: [PATCH] tpm: sleep at least <...> ms in tpm_msleep()

On 5/18/2022 4:21 PM, James Bottomley wrote:
> Actually, this is nothing to do with the TIMEOUTS_A-D: those are the
> maximum times before a command should complete.  This is the minimum
> time we should wait between pokes of the TPM to see if it is ready.
> Usually the use case is:
> 
> while (read device status gives not ready)
>     tpm_msleep(something)
> 
> The tpm_msleep gives up CPU control (to prevent huge amounts of busy
> waiting) but before 424eaf910c32 ("tpm: reduce polling time to usecs
> for even finer granularity") we would sleep for an entire tick (time
> taken to make the process runnable) before the next poll, and since
> most TPM commands don't return immediately, that was a gate on how fast
> you could do simple TPM operations (like PCR extend).
> 
> As far as I know, no TCG spec gives any details of the minimum wait
> time between poll cycles, so this is really something the manufacturer
> has to tell us.
> 
> Just for completeness, my soak test did run to completion, but my TPM
> has since failed and dropped off the bus, so simply reverting this
> patch (5ef924d9e2e8) isn't sufficient to fully fix my problem.

[FYI]

The TPM vendors explained that polling interrupts TPM command
processing. This will make commands take longer.

They recommend adaptive sleep time based on (at least) the
command.  E.g., getcapability, pcrread, ... are fast so a short
sleep is appropriate.  create, createprimary are slow so
a longer sleep will have better performance.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4490 bytes)