On Mon, 2020-12-14 at 10:50 +0100, Dafna Hirschfeld wrote: > Am 11.12.20 um 18:57 schrieb Jarkko Sakkinen: [...] > > But how does this patch deal with TPM2? > > It doesn't, I was not sure if there is need to keep consistent > behavior between 1.2 and 2. I can send next version with the same > behavior for TPM 2. This comes up a lot, so let me give my view that this really has to be our requirement going forward. TPM 1.2 is pretty much a dead device and, thanks to being sha1 only, it's definitely not used to provide security in any serious devices anymore. So effectively any patch which is TPM 1.2 only is either because there's a problem in a legacy system which was fixed in 2.0 or because for some reason the patch producer is working on a legacy system, but it also needs to be provided for TPM 2.0. On this patch, I've got a TPM 2.0 which I can trigger into failure mode on demand (just not get it back again without a power cycle). Since it does correctly respond TPM_RC_FAILURE to every command, it could be attached with no command restriction. The problem is that TPM 2 is an agile device so we need to probe some of its characteristics on attach, which we can't if it's in a failed state. So if we're going to attach a failed TPM 2, we're going to have to make assumptions about the probed values. What do we use as the assumptions for things like number of PCRS (24 woud be reasonable) and hashes and banks (sha1 and sha256), attribute table? The problem here is we only probe this at attach, so if the TPM somehow unfails, all of the assumptions are likely to be wrong and we're going to get issues ... this last bit argues that we should restrict the command list to make sure we don't send it a command with incorrect assumptions. James
