* TPM legacy @ 2018-11-30 23:35 Jarkko Sakkinen 2018-12-02 15:23 ` Mimi Zohar 0 siblings, 1 reply; 14+ messages in thread From: Jarkko Sakkinen @ 2018-11-30 23:35 UTC (permalink / raw) To: linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: TPM legacy 2018-11-30 23:35 TPM legacy Jarkko Sakkinen @ 2018-12-02 15:23 ` Mimi Zohar 2018-12-02 18:29 ` James Bottomley 2018-12-02 23:08 ` Jarkko Sakkinen 0 siblings, 2 replies; 14+ messages in thread From: Mimi Zohar @ 2018-12-02 15:23 UTC (permalink / raw) To: Jarkko Sakkinen, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: TPM legacy 2018-12-02 15:23 ` Mimi Zohar @ 2018-12-02 18:29 ` James Bottomley 2018-12-02 23:13 ` Jarkko Sakkinen 2018-12-02 23:08 ` Jarkko Sakkinen 1 sibling, 1 reply; 14+ messages in thread From: James Bottomley @ 2018-12-02 18:29 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: TPM legacy 2018-12-02 18:29 ` James Bottomley @ 2018-12-02 23:13 ` Jarkko Sakkinen 2018-12-03 15:01 ` Aw: " Peter Huewe 0 siblings, 1 reply; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-02 23:13 UTC (permalink / raw) To: James Bottomley; +Cc: Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Aw: Re: TPM legacy 2018-12-02 23:13 ` Jarkko Sakkinen @ 2018-12-03 15:01 ` Peter Huewe 2018-12-03 17:29 ` Jason Gunthorpe 2018-12-03 17:30 ` Jarkko Sakkinen 0 siblings, 2 replies; 14+ messages in thread From: Peter Huewe @ 2018-12-03 15:01 UTC (permalink / raw) To: Jarkko Sakkinen; +Cc: James Bottomley, Mimi Zohar, linux-integrity 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 15:01 ` Aw: " Peter Huewe @ 2018-12-03 17:29 ` Jason Gunthorpe 2018-12-03 17:55 ` Jarkko Sakkinen 2018-12-03 17:30 ` Jarkko Sakkinen 1 sibling, 1 reply; 14+ messages in thread From: Jason Gunthorpe @ 2018-12-03 17:29 UTC (permalink / raw) To: Peter Huewe; +Cc: Jarkko Sakkinen, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 17:29 ` Jason Gunthorpe @ 2018-12-03 17:55 ` Jarkko Sakkinen 2018-12-03 17:55 ` Jarkko Sakkinen 0 siblings, 1 reply; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-03 17:55 UTC (permalink / raw) To: Jason Gunthorpe; +Cc: Peter Huewe, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 17:55 ` Jarkko Sakkinen @ 2018-12-03 17:55 ` Jarkko Sakkinen 2018-12-03 18:00 ` Peter Huewe 0 siblings, 1 reply; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-03 17:55 UTC (permalink / raw) To: Jason Gunthorpe; +Cc: Peter Huewe, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 17:55 ` Jarkko Sakkinen @ 2018-12-03 18:00 ` Peter Huewe 2018-12-03 18:09 ` Jason Gunthorpe 0 siblings, 1 reply; 14+ messages in thread From: Peter Huewe @ 2018-12-03 18:00 UTC (permalink / raw) To: Jarkko Sakkinen, Jason Gunthorpe Cc: James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 18:00 ` Peter Huewe @ 2018-12-03 18:09 ` Jason Gunthorpe 2018-12-03 18:15 ` Jarkko Sakkinen 0 siblings, 1 reply; 14+ messages in thread From: Jason Gunthorpe @ 2018-12-03 18:09 UTC (permalink / raw) To: Peter Huewe; +Cc: Jarkko Sakkinen, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 18:09 ` Jason Gunthorpe @ 2018-12-03 18:15 ` Jarkko Sakkinen 2018-12-03 18:15 ` Jarkko Sakkinen 0 siblings, 1 reply; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-03 18:15 UTC (permalink / raw) To: Jason Gunthorpe; +Cc: Peter Huewe, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 18:15 ` Jarkko Sakkinen @ 2018-12-03 18:15 ` Jarkko Sakkinen 0 siblings, 0 replies; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-03 18:15 UTC (permalink / raw) To: Jason Gunthorpe; +Cc: Peter Huewe, James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: TPM legacy 2018-12-03 15:01 ` Aw: " Peter Huewe 2018-12-03 17:29 ` Jason Gunthorpe @ 2018-12-03 17:30 ` Jarkko Sakkinen 1 sibling, 0 replies; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-03 17:30 UTC (permalink / raw) To: Peter Huewe; +Cc: James Bottomley, Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: TPM legacy 2018-12-02 15:23 ` Mimi Zohar 2018-12-02 18:29 ` James Bottomley @ 2018-12-02 23:08 ` Jarkko Sakkinen 1 sibling, 0 replies; 14+ messages in thread From: Jarkko Sakkinen @ 2018-12-02 23:08 UTC (permalink / raw) To: Mimi Zohar; +Cc: linux-integrity 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-12-03 18:16 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-30 23:35 TPM legacy Jarkko Sakkinen 2018-12-02 15:23 ` Mimi Zohar 2018-12-02 18:29 ` James Bottomley 2018-12-02 23:13 ` Jarkko Sakkinen 2018-12-03 15:01 ` Aw: " Peter Huewe 2018-12-03 17:29 ` Jason Gunthorpe 2018-12-03 17:55 ` Jarkko Sakkinen 2018-12-03 17:55 ` Jarkko Sakkinen 2018-12-03 18:00 ` Peter Huewe 2018-12-03 18:09 ` Jason Gunthorpe 2018-12-03 18:15 ` Jarkko Sakkinen 2018-12-03 18:15 ` Jarkko Sakkinen 2018-12-03 17:30 ` Jarkko Sakkinen 2018-12-02 23:08 ` Jarkko Sakkinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.