Re: TPM legacy

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2018-12-02 at 10:23 -0500, Mimi Zohar wrote:
> On Fri, 2018-11-30 at 15:35 -0800, Jarkko Sakkinen wrote:
> > 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.
> 
> New systems might be shipping with only TPM 2.0, but it still needs
> to be supported for existing systems, probably for quite a while.
>  Having the option to build the kernel with TPM 1.2, TPM 2.0 or both,
> is acceptable.

The distros won't thank you for yet another kconfig option. ,
especially one which could cause regressions if they choose the wrong
value. However, having a hidden one which could be activated by driver
might work ... on the other hand almost all the current drivers support
both 1.2 and 2.0 so they'd all need splitting.

The other thing that should give us pause is this:

jejb@jarvis:~/git/linux/drivers/char/tpm> size tpm.o
   text	   data	    bss	    dec	    hex	
filename
  35247	   1120	     32	  36399	   8e2f	
tpm.o

Currently the combined tpm subsystem (without drivers) is less than 36k
of code, so is splitting it up valuable?  I think you're going to find
we have a reasonable abstraction of sharing, so taking out 1.x by
config will likely save less than 10k of code ... is that worth the
effort?

James