TPM legacy

TPM legacy

[Jarkko Sakkinen]

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.

/Jarkko

Re: TPM legacy

[Mimi Zohar]

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.

Mimi

Re: TPM legacy

[James Bottomley]

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

Re: TPM legacy

[Jarkko Sakkinen]

On Sun, Dec 02, 2018 at 10:23:46AM -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.

I guess it would be sufficient to just have an option to compile TPM 1.x
out for starters as the real use case is devices with fTPM. Hard to see
much benefit on supporting compiling TPM 2.0 support out. Obviously,
TCG_TPM1 would be by default off.

/Jarkko

Re: TPM legacy

[Jarkko Sakkinen]

On Sun, Dec 02, 2018 at 10:29:26AM -0800, James Bottomley wrote:
> 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.

By default on (i.e. have TPM 1.x) and with a well thought documentation
should not be too bad.

> 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?

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.

It is fairly easy to do as TPM 1.x commands have been already put into
their own file thanks to Tomas.

/Jarkko

Aw: Re: TPM legacy

[Peter Huewe]

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.

Re: Re: TPM legacy

[Jason Gunthorpe]

On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:

> 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...

I also wanted to do this, I feel like these drivers probably don't
work any more after all the churn in the past few years..

Jason

Re: Re: TPM legacy

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:
> 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.

If you submit a patch I will put it to linux-next right after 4.20 PR.

/Jarkko

Re: Re: TPM legacy

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 10:29:22AM -0700, Jason Gunthorpe wrote:
> On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:
> 
> > 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...
> 
> I also wanted to do this, I feel like these drivers probably don't
> work any more after all the churn in the past few years..

I'm with you on this but yeah, better to do it now so that it gets
maximum exposure in linux-next (i.e. would land to 4.22).

/Jarkko

Re: Re: TPM legacy

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 09:55:09AM -0800, Jarkko Sakkinen wrote:
> On Mon, Dec 03, 2018 at 10:29:22AM -0700, Jason Gunthorpe wrote:
> > On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:
> > 
> > > 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...
> > 
> > I also wanted to do this, I feel like these drivers probably don't
> > work any more after all the churn in the past few years..
> 
> I'm with you on this but yeah, better to do it now so that it gets
> maximum exposure in linux-next (i.e. would land to 4.22).

And superimportat to CC this commit also to LSM.

/Jarkko

Re: Re: TPM legacy

[Peter Huewe]

Am 3. Dezember 2018 18:55:46 MEZ schrieb Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>:
>On Mon, Dec 03, 2018 at 09:55:09AM -0800, Jarkko Sakkinen wrote:
>> On Mon, Dec 03, 2018 at 10:29:22AM -0700, Jason Gunthorpe wrote:
>> > On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:
>> > 
>> > > 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...
>> > 
>> > I also wanted to do this, I feel like these drivers probably don't
>> > work any more after all the churn in the past few years..
>> 
>> I'm with you on this but yeah, better to do it now so that it gets
>> maximum exposure in linux-next (i.e. would land to 4.22).
>
>And superimportat to CC this commit also to LSM.
>
>/Jarkko
Correct would be to move them to stagimg first.
See my thread on ksummit-discuss for details.
Peter

-- 
Sent from my mobile

Re: Re: TPM legacy

[Jason Gunthorpe]

On Mon, Dec 03, 2018 at 07:00:26PM +0100, Peter Huewe wrote:
> 
> 
> Am 3. Dezember 2018 18:55:46 MEZ schrieb Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>:
> >On Mon, Dec 03, 2018 at 09:55:09AM -0800, Jarkko Sakkinen wrote:
> >> On Mon, Dec 03, 2018 at 10:29:22AM -0700, Jason Gunthorpe wrote:
> >> > On Mon, Dec 03, 2018 at 04:01:38PM +0100, Peter Huewe wrote:
> >> > 
> >> > > 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...
> >> > 
> >> > I also wanted to do this, I feel like these drivers probably don't
> >> > work any more after all the churn in the past few years..
> >> 
> >> I'm with you on this but yeah, better to do it now so that it gets
> >> maximum exposure in linux-next (i.e. would land to 4.22).
> >
> >And superimportat to CC this commit also to LSM.
> >
> >/Jarkko
> Correct would be to move them to stagimg first.
> See my thread on ksummit-discuss for details.

I thought we decided not to do that anymore? Linus said just delete
them. If someone wants it back then git-revert will do the job.

If you want to do partways then flag the kconfig entries with
CONFIG_BROKEN for a cycle..

Jason

Re: Re: TPM legacy

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 11:09:47AM -0700, Jason Gunthorpe wrote:
> I thought we decided not to do that anymore? Linus said just delete
> them. If someone wants it back then git-revert will do the job.
> 
> If you want to do partways then flag the kconfig entries with
> CONFIG_BROKEN for a cycle..

We should just delete them w/o extra steps.

I'll apply the patch right after PR.

/Jarkko

Re: Re: TPM legacy

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 10:15:07AM -0800, Jarkko Sakkinen wrote:
> On Mon, Dec 03, 2018 at 11:09:47AM -0700, Jason Gunthorpe wrote:
> > I thought we decided not to do that anymore? Linus said just delete
> > them. If someone wants it back then git-revert will do the job.
> > 
> > If you want to do partways then flag the kconfig entries with
> > CONFIG_BROKEN for a cycle..
> 
> We should just delete them w/o extra steps.
> 
> I'll apply the patch right after PR.

Doing PR Mon/Tue next week.

/Jarkko