Hi, > Some things that came up at LSS. > > First, would it be time to drop 1.1b bits? What advantages this would > bring? AFAIK Peter is a strong supporter of this. > In the hall way discussions, I talked with Tomas Winkler that it would > make sense to add CONFIG_TCG_TPM1 flag to completely leave out all TPM > 1.x bits from the kernel. > > TPM 1.x stuff is not exactly legacy but especially on IoT does not make > sense to carry that code with. > It is not only a size question. All unused code is always potential > attack surface. If the option is by default off and properly documented, > it should be IMHO ok. We have to differentiate a few things here: There are - TPM 1.1b (proprietary protocols), - TPM1.2 TIS based, - TPM1.2 TIS deviations (like i2c/spi) - TPM2.0 TIS/FIFO based, - TPM2.0 CRB based TPMs. The only thing I would want to get rid of are the *1.1b based* drivers - they are probably end of life since quite some time. The TIS driver&specification has been around since 2005 if not longer... Nobody has hardware or systems to test 1.1b devices anymore - and there your words are true - these are potential attack surfaces as they are unmaintained stuff. e.g. the tpm_atmel.c or tpm_nsc or tpm_infineon or the iTPM workarounds. By removing these, you can probably streamline all tis based tpm drivers (including the proprietary i2c/spi drivers as they are based on TIS) and architecture a cleaner interface. For tis based tpms, go left, for crb based tpms go right. Since TIS and FIFO are not really different, you save nothing by removing 1.2 support there. 1.2 TPMs are still shipping in huge numbers and will follow us for the next XX years. So dropping or configuring out 1.2 is currently not an optoion and I would certainly nack any attempt at the moment. I don't think you would really save very much by factoring out the 1.2 commandset and at the moment it would confuse more than it would help. Especially if you think about systems were you can switch between 1.2 and 2.0 with a simple reboot. And the code size argument - we added a fullblown resource manager, thinking about adding encrypted sessions per default and are worried about a few bytes for the TPM1.2 commands??? If we really think about size, you would have to restart from scratch - and not only think about code size but especially ram size, e.g. the 4k buffer we statically allocate.... Thanks, Peter´ p.s.: the opinion above is my own, not necessarily my employers.
