TPM legacy
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
Mimi Zohar
maintainerQuoted 7 lines · 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.
Quoted 6 lines
In the hall way discussions, I talked with Tomas Winkler that it would make sense to add
CONFIG_TCG_TPM1flag 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
James Bottomley
maintainerQuoted 12 lines · Mimi Zohar
Quoted 11 lines · 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_TPM1flag to completely leave out all TPM 1.x bits from the kernel.
Quoted 7 lines
Quoted 2 lines
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
Quoted 12 lines · Mimi Zohar
Quoted 11 lines · 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_TPM1flag to completely leave out all TPM 1.x bits from the kernel.
Quoted 7 lines
Quoted 2 lines
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
Quoted 5 lines · James Bottomley
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.
Quoted 8 lines
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
Quoted 5 lines
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
Hi,
Quoted 9 lines
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_TPM1flag to completely leave out all TPM 1.x bits from the kernel.
Quoted 6 lines
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.
Quoted 3 lines · Peter Huewe
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
Quoted 7 lines · Peter Huewe
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. thetpm_atmel.cortpm_nscortpm_infineonor the iTPM workarounds.
If you submit a patch I will put it to linux-next right after 4.20 PR.
/Jarkko
Quoted 8 lines · Jason Gunthorpe
Quoted 3 lines · Peter Huewe
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
Quoted 7 lines · Jarkko Sakkinen
Quoted 6 lines · Jason Gunthorpe
Quoted 3 lines · Peter Huewe
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...
Quoted 5 lines
Quoted 2 lines
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
Am 3. Dezember 2018 18:55:46 MEZ schrieb Jarkko Sakkinen <[email protected]>:
Quoted 13 lines · Jarkko Sakkinen
Quoted 5 lines · Jason Gunthorpe
Quoted 4 lines · Peter Huewe
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
TIS driver&specification has been around since 2005 if not
longer...
Quoted 4 lines
Quoted 3 lines
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..
Quoted 6 lines
Quoted 2 lines
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
Signature · 1 line
Sent from my mobile
Quoted 16 lines · Peter Huewe
Am 3. Dezember 2018 18:55:46 MEZ schrieb Jarkko Sakkinen <[email protected]>:
Quoted 13 lines · Jarkko Sakkinen
Quoted 5 lines · Jason Gunthorpe
Quoted 4 lines · Peter Huewe
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
TIS driver&specification has been around since 2005 if not
longer...
Quoted 4 lines
Quoted 3 lines
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..
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 5 lines · Jason Gunthorpe
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_BROKENfor a cycle..
We should just delete them w/o extra steps.
I'll apply the patch right after PR.
/Jarkko
Quoted 10 lines · Jarkko Sakkinen
Quoted 5 lines · Jason Gunthorpe
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_BROKENfor 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