| Message ID | 20190415155636.32748-1-sashal@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ftpm: a firmware based TPM driver | expand |
On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: >From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > >Changes since v2: > > - Drop the devicetree bindings patch (we don't add any new ones). > - More code cleanups based on Jason Gunthorpe's review. > >Sasha Levin (2): > ftpm: firmware TPM running in TEE > ftpm: add documentation for ftpm driver Ping? Does anyone have any objections to this? -- Thanks, Sasha
+ TEE ML Hi Sasha, Firstly apologies for my comments here as I recently joined linux-integrity ML so I don't have other patches in my inbox. Also, it would be nice if you could cc TEE ML in future patches, so that people are aware of such interesting use-cases and may provide some feedback. On Tue, 7 May 2019 at 23:10, Sasha Levin <sashal@kernel.org> wrote: > > On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > >From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > >Changes since v2: > > > > - Drop the devicetree bindings patch (we don't add any new ones). > > - More code cleanups based on Jason Gunthorpe's review. > > > >Sasha Levin (2): > > ftpm: firmware TPM running in TEE > > ftpm: add documentation for ftpm driver > > Ping? Does anyone have any objections to this? > From [PATCH v3 1/2] ftpm: firmware TPM running in TEE: > +static const struct of_device_id of_ftpm_tee_ids[] = { > + { .compatible = "microsoft,ftpm" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids); > + > +static struct platform_driver ftpm_tee_driver = { > + .driver = { > + .name = DRIVER_NAME, > + .of_match_table = of_match_ptr(of_ftpm_tee_ids), > + }, > + .probe = ftpm_tee_probe, > + .remove = ftpm_tee_remove, > +}; > + > +module_platform_driver(ftpm_tee_driver); Here this fTPM driver (seems to communicate with OP-TEE based TA) should register on TEE bus [1] rather than platform bus as its actual dependency is on TEE driver rather than using deferred probe to meet its dependency. Have a look at OP-TEE based RNG driver here [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc1db9d105915021260eb241661b8e96f5c0f1a [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fe8b1cc6a03c46b3061e808256d39dcebd0d0f0 -Sumit > -- > Thanks, > Sasha
On Wed, May 08, 2019 at 10:11:54AM +0530, Sumit Garg wrote: > + TEE ML > > Hi Sasha, > > Firstly apologies for my comments here as I recently joined > linux-integrity ML so I don't have other patches in my inbox. Also, it > would be nice if you could cc TEE ML in future patches, so that people > are aware of such interesting use-cases and may provide some feedback. If this kind is desire exists then shouldn't it be captured in MAINTAINERS? Daniel. > > On Tue, 7 May 2019 at 23:10, Sasha Levin <sashal@kernel.org> wrote: > > > > On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > >From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > > >Changes since v2: > > > > > > - Drop the devicetree bindings patch (we don't add any new ones). > > > - More code cleanups based on Jason Gunthorpe's review. > > > > > >Sasha Levin (2): > > > ftpm: firmware TPM running in TEE > > > ftpm: add documentation for ftpm driver > > > > Ping? Does anyone have any objections to this? > > > > From [PATCH v3 1/2] ftpm: firmware TPM running in TEE: > > > +static const struct of_device_id of_ftpm_tee_ids[] = { > > + { .compatible = "microsoft,ftpm" }, > > + { } > > +}; > > +MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids); > > + > > +static struct platform_driver ftpm_tee_driver = { > > + .driver = { > > + .name = DRIVER_NAME, > > + .of_match_table = of_match_ptr(of_ftpm_tee_ids), > > + }, > > + .probe = ftpm_tee_probe, > > + .remove = ftpm_tee_remove, > > +}; > > + > > +module_platform_driver(ftpm_tee_driver); > > Here this fTPM driver (seems to communicate with OP-TEE based TA) > should register on TEE bus [1] rather than platform bus as its actual > dependency is on TEE driver rather than using deferred probe to meet > its dependency. Have a look at OP-TEE based RNG driver here [2]. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc1db9d105915021260eb241661b8e96f5c0f1a > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fe8b1cc6a03c46b3061e808256d39dcebd0d0f0 > > -Sumit > > > -- > > Thanks, > > Sasha
On Wed, 8 May 2019 at 13:32, Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Wed, May 08, 2019 at 10:11:54AM +0530, Sumit Garg wrote: > > + TEE ML > > > > Hi Sasha, > > > > Firstly apologies for my comments here as I recently joined > > linux-integrity ML so I don't have other patches in my inbox. Also, it > > would be nice if you could cc TEE ML in future patches, so that people > > are aware of such interesting use-cases and may provide some feedback. > > If this kind is desire exists then shouldn't it be captured in > MAINTAINERS? > Makes sense, will send a patch to capture it in MAINTAINERS file. -Sumit > > Daniel. > > > > > On Tue, 7 May 2019 at 23:10, Sasha Levin <sashal@kernel.org> wrote: > > > > > > On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > >From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > > > > >Changes since v2: > > > > > > > > - Drop the devicetree bindings patch (we don't add any new ones). > > > > - More code cleanups based on Jason Gunthorpe's review. > > > > > > > >Sasha Levin (2): > > > > ftpm: firmware TPM running in TEE > > > > ftpm: add documentation for ftpm driver > > > > > > Ping? Does anyone have any objections to this? > > > > > > > From [PATCH v3 1/2] ftpm: firmware TPM running in TEE: > > > > > +static const struct of_device_id of_ftpm_tee_ids[] = { > > > + { .compatible = "microsoft,ftpm" }, > > > + { } > > > +}; > > > +MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids); > > > + > > > +static struct platform_driver ftpm_tee_driver = { > > > + .driver = { > > > + .name = DRIVER_NAME, > > > + .of_match_table = of_match_ptr(of_ftpm_tee_ids), > > > + }, > > > + .probe = ftpm_tee_probe, > > > + .remove = ftpm_tee_remove, > > > +}; > > > + > > > +module_platform_driver(ftpm_tee_driver); > > > > Here this fTPM driver (seems to communicate with OP-TEE based TA) > > should register on TEE bus [1] rather than platform bus as its actual > > dependency is on TEE driver rather than using deferred probe to meet > > its dependency. Have a look at OP-TEE based RNG driver here [2]. > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc1db9d105915021260eb241661b8e96f5c0f1a > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fe8b1cc6a03c46b3061e808256d39dcebd0d0f0 > > > > -Sumit > > > > > -- > > > Thanks, > > > Sasha
On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > Changes since v2: > > > > - Drop the devicetree bindings patch (we don't add any new ones). > > - More code cleanups based on Jason Gunthorpe's review. > > > > Sasha Levin (2): > > ftpm: firmware TPM running in TEE > > ftpm: add documentation for ftpm driver > > Ping? Does anyone have any objections to this? Sorry I've been on vacation week before last week and last week I was extremely busy because I had been on vacation. This in my TODO list. Will look into it tomorrow in detail. Apologies for the delay with this! /Jarkko
On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> >> > >> > Changes since v2: >> > >> > - Drop the devicetree bindings patch (we don't add any new ones). >> > - More code cleanups based on Jason Gunthorpe's review. >> > >> > Sasha Levin (2): >> > ftpm: firmware TPM running in TEE >> > ftpm: add documentation for ftpm driver >> >> Ping? Does anyone have any objections to this? > >Sorry I've been on vacation week before last week and last week >I was extremely busy because I had been on vacation. This in >my TODO list. Will look into it tomorrow in detail. > >Apologies for the delay with this! Hi Jarkko, If there aren't any big objections to this, can we get it merged in? We'll be happy to address any comments that come up. -- Thanks, Sasha
On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> wrote: > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > >> > > >> > Changes since v2: > >> > > >> > - Drop the devicetree bindings patch (we don't add any new ones). > >> > - More code cleanups based on Jason Gunthorpe's review. > >> > > >> > Sasha Levin (2): > >> > ftpm: firmware TPM running in TEE > >> > ftpm: add documentation for ftpm driver > >> > >> Ping? Does anyone have any objections to this? > > > >Sorry I've been on vacation week before last week and last week > >I was extremely busy because I had been on vacation. This in > >my TODO list. Will look into it tomorrow in detail. > > > >Apologies for the delay with this! > > Hi Jarkko, > > If there aren't any big objections to this, can we get it merged in? > We'll be happy to address any comments that come up. I guess you have missed or ignored this comment [1]. Please address it. [1] https://lkml.org/lkml/2019/5/8/11 -Sumit > > -- > Thanks, > Sasha
> -----Original Message----- > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Tuesday, May 14, 2019 7:02 PM > To: Sasha Levin <sashal@kernel.org> > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > kernel@microsoft.com>; Thirupathaiah Annapureddy <thiruan@microsoft.com>; > Bryan Kelly (CSI) <bryankel@microsoft.com> > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> wrote: > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > >> > > > >> > Changes since v2: > > >> > > > >> > - Drop the devicetree bindings patch (we don't add any new ones). > > >> > - More code cleanups based on Jason Gunthorpe's review. > > >> > > > >> > Sasha Levin (2): > > >> > ftpm: firmware TPM running in TEE > > >> > ftpm: add documentation for ftpm driver > > >> > > >> Ping? Does anyone have any objections to this? > > > > > >Sorry I've been on vacation week before last week and last week > > >I was extremely busy because I had been on vacation. This in > > >my TODO list. Will look into it tomorrow in detail. > > > > > >Apologies for the delay with this! > > > > Hi Jarkko, > > > > If there aren't any big objections to this, can we get it merged in? > > We'll be happy to address any comments that come up. > > I guess you have missed or ignored this comment [1]. Please address it. > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > -Sumit Thanks for reviewing and adding comments. We tried to use TEE bus framework you suggested for fTPM enumeration. We were not able to pass the TCG Logs collected by the boot loaders. Currently there are 3 ways to pass TCG Logs based on the code in drivers/char/tpm/eventlog: 1. ACPI Table 2. EFI Table 3. OF Device node properties Our ARM system is booting using U-boot and Device Tree. So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. We needed to use OF device node properties to pass TCG2 Logs. TEE bus enumeration framework does not work for our use case due to the above. Is it possible to add flexibility in TEE bus enumeration framework to support platform specific properties through OF nodes or ACPI? > > > > > -- > > Thanks, > > Sasha
On Thu, 16 May 2019 at 06:30, Thirupathaiah Annapureddy <thiruan@microsoft.com> wrote: > > > > > -----Original Message----- > > From: Sumit Garg <sumit.garg@linaro.org> > > Sent: Tuesday, May 14, 2019 7:02 PM > > To: Sasha Levin <sashal@kernel.org> > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; > > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > > kernel@microsoft.com>; Thirupathaiah Annapureddy <thiruan@microsoft.com>; > > Bryan Kelly (CSI) <bryankel@microsoft.com> > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> wrote: > > > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > >> > > > > >> > Changes since v2: > > > >> > > > > >> > - Drop the devicetree bindings patch (we don't add any new ones). > > > >> > - More code cleanups based on Jason Gunthorpe's review. > > > >> > > > > >> > Sasha Levin (2): > > > >> > ftpm: firmware TPM running in TEE > > > >> > ftpm: add documentation for ftpm driver > > > >> > > > >> Ping? Does anyone have any objections to this? > > > > > > > >Sorry I've been on vacation week before last week and last week > > > >I was extremely busy because I had been on vacation. This in > > > >my TODO list. Will look into it tomorrow in detail. > > > > > > > >Apologies for the delay with this! > > > > > > Hi Jarkko, > > > > > > If there aren't any big objections to this, can we get it merged in? > > > We'll be happy to address any comments that come up. > > > > I guess you have missed or ignored this comment [1]. Please address it. > > > > [1] > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > > > -Sumit > > Thanks for reviewing and adding comments. > > We tried to use TEE bus framework you suggested for fTPM enumeration. > We were not able to pass the TCG Logs collected by the boot loaders. > > Currently there are 3 ways to pass TCG Logs based on the code > in drivers/char/tpm/eventlog: > > 1. ACPI Table > 2. EFI Table > 3. OF Device node properties > > Our ARM system is booting using U-boot and Device Tree. > So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. > We needed to use OF device node properties to pass TCG2 Logs. > TEE bus enumeration framework does not work for our use case due to the above. Firstly let me clarify that this framework is intended to communicate with TEE based services/devices rather than boot loader. And in this case fTPM being a TEE based service, so this framework should be used. > > Is it possible to add flexibility in TEE bus enumeration framework to support > platform specific properties through OF nodes or ACPI? > As you mentioned above, TCG logs are collected by boot loader. So it should find a way to pass them to Linux. How about if boot loader register these TCG logs with fTPM TA which could be fetched during fTPM driver probe or new api like tpm_read_log_tee()? This is something similar to what I used in optee-rng [1] driver to fetch RNG properties. [1] https://github.com/torvalds/linux/blob/master/drivers/char/hw_random/optee-rng.c#L176 -Sumit > > > > > > > > -- > > > Thanks, > > > Sasha
> -----Original Message----- > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Thursday, May 16, 2019 12:06 AM > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > corbet@lwn.net; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft Linux > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > <bryankel@microsoft.com> > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > On Thu, 16 May 2019 at 06:30, Thirupathaiah Annapureddy > <thiruan@microsoft.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Sumit Garg <sumit.garg@linaro.org> > > > Sent: Tuesday, May 14, 2019 7:02 PM > > > To: Sasha Levin <sashal@kernel.org> > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; > peterhuewe@gmx.de; > > > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > > > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > > > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > > > kernel@microsoft.com>; Thirupathaiah Annapureddy > <thiruan@microsoft.com>; > > > Bryan Kelly (CSI) <bryankel@microsoft.com> > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> wrote: > > > > > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > >> > > > > > >> > Changes since v2: > > > > >> > > > > > >> > - Drop the devicetree bindings patch (we don't add any new > ones). > > > > >> > - More code cleanups based on Jason Gunthorpe's review. > > > > >> > > > > > >> > Sasha Levin (2): > > > > >> > ftpm: firmware TPM running in TEE > > > > >> > ftpm: add documentation for ftpm driver > > > > >> > > > > >> Ping? Does anyone have any objections to this? > > > > > > > > > >Sorry I've been on vacation week before last week and last week > > > > >I was extremely busy because I had been on vacation. This in > > > > >my TODO list. Will look into it tomorrow in detail. > > > > > > > > > >Apologies for the delay with this! > > > > > > > > Hi Jarkko, > > > > > > > > If there aren't any big objections to this, can we get it merged in? > > > > We'll be happy to address any comments that come up. > > > > > > I guess you have missed or ignored this comment [1]. Please address it. > > > > > > [1] > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > > > > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > > > > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > > > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > > > > > -Sumit > > > > Thanks for reviewing and adding comments. > > > > We tried to use TEE bus framework you suggested for fTPM enumeration. > > We were not able to pass the TCG Logs collected by the boot loaders. > > > > Currently there are 3 ways to pass TCG Logs based on the code > > in drivers/char/tpm/eventlog: > > > > 1. ACPI Table > > 2. EFI Table > > 3. OF Device node properties > > > > Our ARM system is booting using U-boot and Device Tree. > > So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. > > We needed to use OF device node properties to pass TCG2 Logs. > > TEE bus enumeration framework does not work for our use case due to the > above. > > Firstly let me clarify that this framework is intended to communicate > with TEE based services/devices rather than boot loader. And in this > case fTPM being a TEE based service, so this framework should be used. > It does not work for our use case. We gave enough justification so far. TEE bus enumeration needs to be flexible to support our use case and more future use cases. > > > > Is it possible to add flexibility in TEE bus enumeration framework to > support > > platform specific properties through OF nodes or ACPI? > > > > As you mentioned above, TCG logs are collected by boot loader. So it > should find a way to pass them to Linux. > > How about if boot loader register these TCG logs with fTPM TA which > could be fetched during fTPM driver probe or new api like > tpm_read_log_tee()? And then how does fTPM driver pass TCG Logs to the TPM framework? It requires changes to the upstream TPM framework to ask the driver explicitly for the TCG Logs. Note that this also requires changes to the fTPM TA that has been existing for few years. Is it not possible to add flexibility in TEE bus enumeration framework to support platform specific properties through OF nodes or ACPI? Devices enumerated by buses such as i2c can read platform specific properties. With this flexibility added, more future use cases through TEE bus. > This is something similar to what I used in > optee-rng [1] driver to fetch RNG properties. > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co > m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fchar%2Fhw_random%2Foptee- > rng.c%23L176&data=02%7C01%7Cthiruan%40microsoft.com%7Cd37438eaf4f9483e4 > 0c708d6d9ccfe0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63693587179549 > 3006&sdata=As9sC45Bl7sZdJKOq0sHz6GmXttMxS80Nn5yvN4vqng%3D&reserved= > 0 > > -Sumit > > > > > > > > > > > > -- > > > > Thanks, > > > > Sasha
+ Rob On Fri, 17 May 2019 at 00:54, Thirupathaiah Annapureddy <thiruan@microsoft.com> wrote: > > > > > -----Original Message----- > > From: Sumit Garg <sumit.garg@linaro.org> > > Sent: Thursday, May 16, 2019 12:06 AM > > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > > corbet@lwn.net; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; > > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft Linux > > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > > <bryankel@microsoft.com> > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > On Thu, 16 May 2019 at 06:30, Thirupathaiah Annapureddy > > <thiruan@microsoft.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Sumit Garg <sumit.garg@linaro.org> > > > > Sent: Tuesday, May 14, 2019 7:02 PM > > > > To: Sasha Levin <sashal@kernel.org> > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; > > peterhuewe@gmx.de; > > > > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > > > > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > > > > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > > > > kernel@microsoft.com>; Thirupathaiah Annapureddy > > <thiruan@microsoft.com>; > > > > Bryan Kelly (CSI) <bryankel@microsoft.com> > > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> wrote: > > > > > > > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > > > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > > > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > > >> > > > > > > >> > Changes since v2: > > > > > >> > > > > > > >> > - Drop the devicetree bindings patch (we don't add any new > > ones). > > > > > >> > - More code cleanups based on Jason Gunthorpe's review. > > > > > >> > > > > > > >> > Sasha Levin (2): > > > > > >> > ftpm: firmware TPM running in TEE > > > > > >> > ftpm: add documentation for ftpm driver > > > > > >> > > > > > >> Ping? Does anyone have any objections to this? > > > > > > > > > > > >Sorry I've been on vacation week before last week and last week > > > > > >I was extremely busy because I had been on vacation. This in > > > > > >my TODO list. Will look into it tomorrow in detail. > > > > > > > > > > > >Apologies for the delay with this! > > > > > > > > > > Hi Jarkko, > > > > > > > > > > If there aren't any big objections to this, can we get it merged in? > > > > > We'll be happy to address any comments that come up. > > > > > > > > I guess you have missed or ignored this comment [1]. Please address it. > > > > > > > > [1] > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > > > > > > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > > > > > > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > > > > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > > > > > > > -Sumit > > > > > > Thanks for reviewing and adding comments. > > > > > > We tried to use TEE bus framework you suggested for fTPM enumeration. > > > We were not able to pass the TCG Logs collected by the boot loaders. > > > > > > Currently there are 3 ways to pass TCG Logs based on the code > > > in drivers/char/tpm/eventlog: > > > > > > 1. ACPI Table > > > 2. EFI Table > > > 3. OF Device node properties > > > > > > Our ARM system is booting using U-boot and Device Tree. > > > So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. > > > We needed to use OF device node properties to pass TCG2 Logs. > > > TEE bus enumeration framework does not work for our use case due to the > > above. > > > > Firstly let me clarify that this framework is intended to communicate > > with TEE based services/devices rather than boot loader. And in this > > case fTPM being a TEE based service, so this framework should be used. > > > It does not work for our use case. We gave enough justification so far. > TEE bus enumeration needs to be flexible to support our use case and > more future use cases. > TEE based services are virtual devices which could be very well be aware about the platform and device driver could easily query these devices for platform specific properties. In case of firmware TPM as a TEE based service, it could easily store the event logs generated during PCR extend operations which could be fetched at runtime. But a real TPM device doesn't possess that storage capability leading to software managing these event logs. > > > > > > Is it possible to add flexibility in TEE bus enumeration framework to > > support > > > platform specific properties through OF nodes or ACPI? > > > > > > > As you mentioned above, TCG logs are collected by boot loader. So it > > should find a way to pass them to Linux. > > > > How about if boot loader register these TCG logs with fTPM TA which > > could be fetched during fTPM driver probe or new api like > > tpm_read_log_tee()? > > And then how does fTPM driver pass TCG Logs to the TPM framework? > It requires changes to the upstream TPM framework to ask the driver > explicitly for the TCG Logs. My suggestion was to add 4th way to pass TCG logs as follows: --- a/drivers/char/tpm/eventlog/common.c +++ b/drivers/char/tpm/eventlog/common.c @@ -95,6 +95,10 @@ static int tpm_read_log(struct tpm_chip *chip) if (rc != -ENODEV) return rc; + rc = tpm_read_log_tee(chip); + if (rc != -ENODEV) + return rc; + return tpm_read_log_of(chip); } --- /dev/null +++ b/drivers/char/tpm/eventlog/tee.c @@ -0,0 +1,43 @@ <snip> +int tpm_read_log_tee(struct tpm_chip *chip) +{ + struct tpm_bios_log *log; + struct ftpm_tee_private *pvt_data; + + log = &chip->log; + if (!strcmp(chip->dev.bus->name, tee_bus_type.name)) + pvt_data = dev_get_drvdata(chip->dev.parent); + else + return -ENODEV; + + // Here you could simply do an invoke command to fetch the TCG logs. + + if (chip->flags & TPM_CHIP_FLAG_TPM2) + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_2; + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; +} > > Note that this also requires changes to the fTPM TA that has been existing for few years. > That's not a sane reason to avoid implementing generic stuff. As there could be other fTPM implementations and specific DT nodes for each which might not be maintainable. BTW, in current implementation also I don't find DT bindings corresponding to DT node used in this patch-set. > Is it not possible to add flexibility in TEE bus enumeration framework to > support platform specific properties through OF nodes or ACPI? > TEE bus framework was designed specifically to avoid OF nodes or ACPI properties. As devices could be intelligent enough to be queried for required properties. > Devices enumerated by buses such as i2c can read platform specific properties. i2c devices are real hardware which could be platform agnostic, so you need to have platform specific properties. -Sumit > With this flexibility added, more future use cases through TEE bus. > > > > This is something similar to what I used in > > optee-rng [1] driver to fetch RNG properties. > > > > [1] > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co > > m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fchar%2Fhw_random%2Foptee- > > rng.c%23L176&data=02%7C01%7Cthiruan%40microsoft.com%7Cd37438eaf4f9483e4 > > 0c708d6d9ccfe0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63693587179549 > > 3006&sdata=As9sC45Bl7sZdJKOq0sHz6GmXttMxS80Nn5yvN4vqng%3D&reserved= > > 0 > > > > -Sumit > > > > > > > > > > > > > > > > -- > > > > > Thanks, > > > > > Sasha
> -----Original Message----- > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Thursday, May 16, 2019 11:57 PM > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > corbet@lwn.net; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft Linux > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > <bryankel@microsoft.com>; Rob Herring <robh+dt@kernel.org> > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > + Rob > > On Fri, 17 May 2019 at 00:54, Thirupathaiah Annapureddy > <thiruan@microsoft.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Sumit Garg <sumit.garg@linaro.org> > > > Sent: Thursday, May 16, 2019 12:06 AM > > > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > > > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > > > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > > > corbet@lwn.net; Linux Kernel Mailing List <linux- > kernel@vger.kernel.org>; > > > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft > Linux > > > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > > > <bryankel@microsoft.com> > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > On Thu, 16 May 2019 at 06:30, Thirupathaiah Annapureddy > > > <thiruan@microsoft.com> wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Sumit Garg <sumit.garg@linaro.org> > > > > > Sent: Tuesday, May 14, 2019 7:02 PM > > > > > To: Sasha Levin <sashal@kernel.org> > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; > > > peterhuewe@gmx.de; > > > > > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > > > > > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > > > > > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > > > > > kernel@microsoft.com>; Thirupathaiah Annapureddy > > > <thiruan@microsoft.com>; > > > > > Bryan Kelly (CSI) <bryankel@microsoft.com> > > > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > > > > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> > wrote: > > > > > > > > > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > > > > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > > > > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > > > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > > > >> > > > > > > > >> > Changes since v2: > > > > > > >> > > > > > > > >> > - Drop the devicetree bindings patch (we don't add any new > > > ones). > > > > > > >> > - More code cleanups based on Jason Gunthorpe's review. > > > > > > >> > > > > > > > >> > Sasha Levin (2): > > > > > > >> > ftpm: firmware TPM running in TEE > > > > > > >> > ftpm: add documentation for ftpm driver > > > > > > >> > > > > > > >> Ping? Does anyone have any objections to this? > > > > > > > > > > > > > >Sorry I've been on vacation week before last week and last week > > > > > > >I was extremely busy because I had been on vacation. This in > > > > > > >my TODO list. Will look into it tomorrow in detail. > > > > > > > > > > > > > >Apologies for the delay with this! > > > > > > > > > > > > Hi Jarkko, > > > > > > > > > > > > If there aren't any big objections to this, can we get it merged > in? > > > > > > We'll be happy to address any comments that come up. > > > > > > > > > > I guess you have missed or ignored this comment [1]. Please address > it. > > > > > > > > > > [1] > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > > > > > > > > > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > > > > > > > > > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > > > > > > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > > > > > > > > > -Sumit > > > > > > > > Thanks for reviewing and adding comments. > > > > > > > > We tried to use TEE bus framework you suggested for fTPM enumeration. > > > > We were not able to pass the TCG Logs collected by the boot loaders. > > > > > > > > Currently there are 3 ways to pass TCG Logs based on the code > > > > in drivers/char/tpm/eventlog: > > > > > > > > 1. ACPI Table > > > > 2. EFI Table > > > > 3. OF Device node properties > > > > > > > > Our ARM system is booting using U-boot and Device Tree. > > > > So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. > > > > We needed to use OF device node properties to pass TCG2 Logs. > > > > TEE bus enumeration framework does not work for our use case due to > the > > > above. > > > > > > Firstly let me clarify that this framework is intended to communicate > > > with TEE based services/devices rather than boot loader. And in this > > > case fTPM being a TEE based service, so this framework should be used. > > > > > It does not work for our use case. We gave enough justification so far. > > TEE bus enumeration needs to be flexible to support our use case and > > more future use cases. > > > > TEE based services are virtual devices which could be very well be > aware about the platform and device driver could easily query these > devices for platform specific properties. In case of firmware TPM as a > TEE based service, it could easily store the event logs generated > during PCR extend operations which could be fetched at runtime. But a > real TPM device doesn't possess that storage capability leading to > software managing these event logs. > > > > > > > > > Is it possible to add flexibility in TEE bus enumeration framework to > > > support > > > > platform specific properties through OF nodes or ACPI? > > > > > > > > > > As you mentioned above, TCG logs are collected by boot loader. So it > > > should find a way to pass them to Linux. > > > > > > How about if boot loader register these TCG logs with fTPM TA which > > > could be fetched during fTPM driver probe or new api like > > > tpm_read_log_tee()? > > > > And then how does fTPM driver pass TCG Logs to the TPM framework? > > It requires changes to the upstream TPM framework to ask the driver > > explicitly for the TCG Logs. > > My suggestion was to add 4th way to pass TCG logs as follows: > > --- a/drivers/char/tpm/eventlog/common.c > +++ b/drivers/char/tpm/eventlog/common.c > @@ -95,6 +95,10 @@ static int tpm_read_log(struct tpm_chip *chip) > if (rc != -ENODEV) > return rc; > > + rc = tpm_read_log_tee(chip); > + if (rc != -ENODEV) > + return rc; > + > return tpm_read_log_of(chip); > } > --- /dev/null > +++ b/drivers/char/tpm/eventlog/tee.c > @@ -0,0 +1,43 @@ > <snip> > +int tpm_read_log_tee(struct tpm_chip *chip) > +{ > + struct tpm_bios_log *log; > + struct ftpm_tee_private *pvt_data; > + > + log = &chip->log; > + if (!strcmp(chip->dev.bus->name, tee_bus_type.name)) > + pvt_data = dev_get_drvdata(chip->dev.parent); > + else > + return -ENODEV; > + > + // Here you could simply do an invoke command to fetch the TCG > logs. > + > + if (chip->flags & TPM_CHIP_FLAG_TPM2) > + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_2; > + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > +} But I do not see a need for this 4th method if TEE bus enumeration framework supports flexibility. The problem is with the TEE bus enumeration. > > > > > Note that this also requires changes to the fTPM TA that has been > existing for few years. > > > > That's not a sane reason to avoid implementing generic stuff. Exactly, TEE bus enumeration framework need to support generic stuff that is expected of a bus driver. You are expecting everything else to be generic enough, but not TEE bus enumeration. > As there > could be other fTPM implementations and specific DT nodes for each > which might not be maintainable. BTW, in current implementation also I > don't find DT bindings corresponding to DT node used in this > patch-set. > > > Is it not possible to add flexibility in TEE bus enumeration framework to > > support platform specific properties through OF nodes or ACPI? > > > > TEE bus framework was designed specifically to avoid OF nodes or ACPI > properties. As devices could be intelligent enough to be queried for > required properties. Is there an expectation that TEE bus enumerated devices to be intelligent? If so, this is another limitation of TEE bus enumeration. Please fix these limitations to make TEE bus enumeration scalable and flexible for future use cases. > > > Devices enumerated by buses such as i2c can read platform specific > properties. > > i2c devices are real hardware which could be platform agnostic, so you > need to have platform specific properties. > > -Sumit > > > With this flexibility added, more future use cases through TEE bus. > > > > > > > This is something similar to what I used in > > > optee-rng [1] driver to fetch RNG properties. > > > > > > [1] > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co > > > > m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fchar%2Fhw_random%2Foptee- > > > > rng.c%23L176&data=02%7C01%7Cthiruan%40microsoft.com%7Cd37438eaf4f9483e4 > > > > 0c708d6d9ccfe0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63693587179549 > > > > 3006&sdata=As9sC45Bl7sZdJKOq0sHz6GmXttMxS80Nn5yvN4vqng%3D&reserved= > > > 0 > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > > > > Sasha
On Fri, 17 May 2019 at 22:53, Thirupathaiah Annapureddy <thiruan@microsoft.com> wrote: > > > > > -----Original Message----- > > From: Sumit Garg <sumit.garg@linaro.org> > > Sent: Thursday, May 16, 2019 11:57 PM > > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > > corbet@lwn.net; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; > > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft Linux > > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > > <bryankel@microsoft.com>; Rob Herring <robh+dt@kernel.org> > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > + Rob > > > > On Fri, 17 May 2019 at 00:54, Thirupathaiah Annapureddy > > <thiruan@microsoft.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Sumit Garg <sumit.garg@linaro.org> > > > > Sent: Thursday, May 16, 2019 12:06 AM > > > > To: Thirupathaiah Annapureddy <thiruan@microsoft.com> > > > > Cc: Sasha Levin <sashal@kernel.org>; Jarkko Sakkinen > > > > <jarkko.sakkinen@linux.intel.com>; peterhuewe@gmx.de; jgg@ziepe.ca; > > > > corbet@lwn.net; Linux Kernel Mailing List <linux- > > kernel@vger.kernel.org>; > > > > linux-doc@vger.kernel.org; linux-integrity@vger.kernel.org; Microsoft > > Linux > > > > Kernel List <linux-kernel@microsoft.com>; Bryan Kelly (CSI) > > > > <bryankel@microsoft.com> > > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > > > On Thu, 16 May 2019 at 06:30, Thirupathaiah Annapureddy > > > > <thiruan@microsoft.com> wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sumit Garg <sumit.garg@linaro.org> > > > > > > Sent: Tuesday, May 14, 2019 7:02 PM > > > > > > To: Sasha Levin <sashal@kernel.org> > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; > > > > peterhuewe@gmx.de; > > > > > > jgg@ziepe.ca; corbet@lwn.net; Linux Kernel Mailing List <linux- > > > > > > kernel@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > > > > > > integrity@vger.kernel.org; Microsoft Linux Kernel List <linux- > > > > > > kernel@microsoft.com>; Thirupathaiah Annapureddy > > > > <thiruan@microsoft.com>; > > > > > > Bryan Kelly (CSI) <bryankel@microsoft.com> > > > > > > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > > > > > > > > > > > On Wed, 15 May 2019 at 01:00, Sasha Levin <sashal@kernel.org> > > wrote: > > > > > > > > > > > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > > > > > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > > > > > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > > > > > > >> > From: "Sasha Levin (Microsoft)" <sashal@kernel.org> > > > > > > > >> > > > > > > > > >> > Changes since v2: > > > > > > > >> > > > > > > > > >> > - Drop the devicetree bindings patch (we don't add any new > > > > ones). > > > > > > > >> > - More code cleanups based on Jason Gunthorpe's review. > > > > > > > >> > > > > > > > > >> > Sasha Levin (2): > > > > > > > >> > ftpm: firmware TPM running in TEE > > > > > > > >> > ftpm: add documentation for ftpm driver > > > > > > > >> > > > > > > > >> Ping? Does anyone have any objections to this? > > > > > > > > > > > > > > > >Sorry I've been on vacation week before last week and last week > > > > > > > >I was extremely busy because I had been on vacation. This in > > > > > > > >my TODO list. Will look into it tomorrow in detail. > > > > > > > > > > > > > > > >Apologies for the delay with this! > > > > > > > > > > > > > > Hi Jarkko, > > > > > > > > > > > > > > If there aren't any big objections to this, can we get it merged > > in? > > > > > > > We'll be happy to address any comments that come up. > > > > > > > > > > > > I guess you have missed or ignored this comment [1]. Please address > > it. > > > > > > > > > > > > [1] > > > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > > > > > > > > > > > > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > > > > > > > > > > > > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > > > > > > > > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > > > > > > > > > > > -Sumit > > > > > > > > > > Thanks for reviewing and adding comments. > > > > > > > > > > We tried to use TEE bus framework you suggested for fTPM enumeration. > > > > > We were not able to pass the TCG Logs collected by the boot loaders. > > > > > > > > > > Currently there are 3 ways to pass TCG Logs based on the code > > > > > in drivers/char/tpm/eventlog: > > > > > > > > > > 1. ACPI Table > > > > > 2. EFI Table > > > > > 3. OF Device node properties > > > > > > > > > > Our ARM system is booting using U-boot and Device Tree. > > > > > So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. > > > > > We needed to use OF device node properties to pass TCG2 Logs. > > > > > TEE bus enumeration framework does not work for our use case due to > > the > > > > above. > > > > > > > > Firstly let me clarify that this framework is intended to communicate > > > > with TEE based services/devices rather than boot loader. And in this > > > > case fTPM being a TEE based service, so this framework should be used. > > > > > > > It does not work for our use case. We gave enough justification so far. > > > TEE bus enumeration needs to be flexible to support our use case and > > > more future use cases. > > > > > > > TEE based services are virtual devices which could be very well be > > aware about the platform and device driver could easily query these > > devices for platform specific properties. In case of firmware TPM as a > > TEE based service, it could easily store the event logs generated > > during PCR extend operations which could be fetched at runtime. But a > > real TPM device doesn't possess that storage capability leading to > > software managing these event logs. > > > > > > > > > > > > Is it possible to add flexibility in TEE bus enumeration framework to > > > > support > > > > > platform specific properties through OF nodes or ACPI? > > > > > > > > > > > > > As you mentioned above, TCG logs are collected by boot loader. So it > > > > should find a way to pass them to Linux. > > > > > > > > How about if boot loader register these TCG logs with fTPM TA which > > > > could be fetched during fTPM driver probe or new api like > > > > tpm_read_log_tee()? > > > > > > And then how does fTPM driver pass TCG Logs to the TPM framework? > > > It requires changes to the upstream TPM framework to ask the driver > > > explicitly for the TCG Logs. > > > > My suggestion was to add 4th way to pass TCG logs as follows: > > > > --- a/drivers/char/tpm/eventlog/common.c > > +++ b/drivers/char/tpm/eventlog/common.c > > @@ -95,6 +95,10 @@ static int tpm_read_log(struct tpm_chip *chip) > > if (rc != -ENODEV) > > return rc; > > > > + rc = tpm_read_log_tee(chip); > > + if (rc != -ENODEV) > > + return rc; > > + > > return tpm_read_log_of(chip); > > } > > --- /dev/null > > +++ b/drivers/char/tpm/eventlog/tee.c > > @@ -0,0 +1,43 @@ > > <snip> > > +int tpm_read_log_tee(struct tpm_chip *chip) > > +{ > > + struct tpm_bios_log *log; > > + struct ftpm_tee_private *pvt_data; > > + > > + log = &chip->log; > > + if (!strcmp(chip->dev.bus->name, tee_bus_type.name)) > > + pvt_data = dev_get_drvdata(chip->dev.parent); > > + else > > + return -ENODEV; > > + > > + // Here you could simply do an invoke command to fetch the TCG > > logs. > > + > > + if (chip->flags & TPM_CHIP_FLAG_TPM2) > > + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_2; > > + return EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > > +} > > But I do not see a need for this 4th method if TEE bus enumeration framework supports flexibility. If there is a way to fetch event logs buffer at runtime from TPM device then why should we rely on DT or ACPI stuff? > The problem is with the TEE bus enumeration. > See my response below. > > > > > > > > Note that this also requires changes to the fTPM TA that has been > > existing for few years. > > > > > > > That's not a sane reason to avoid implementing generic stuff. > > Exactly, TEE bus enumeration framework need to support generic stuff that is expected > of a bus driver. You are expecting everything else to be generic enough, but not TEE bus enumeration. > I guess you are missing the basic TEE bus view. It is an auto-discoverable bus where TAs as devices are detected automatically. It is similar to USB, PCI etc. busses. But in case of Platform, I2C, SPI etc. which are NOT auto-discoverable busses, devices are described in the hardware description language (ACPI or DT). Like in case of TPM, when acting as an I2C based device is represented via a DT node (see section: "2.4 Device population" in Documentation/devicetree/usage-model.txt). And device specific properties are retrieved from corresponding device DT node. But in case of TPM being a TEE based device, detected automatically, you won't have a device DT node to describe its properties but rather those properties need to derived from the device automatically. So in summary, it doesn't seems possible to support TEE devices detected automatically and have properties described in DT unless you hard code DT node path in the driver to provide those properties which doesn't looks like a generic solution. > > As there > > could be other fTPM implementations and specific DT nodes for each > > which might not be maintainable. BTW, in current implementation also I > > don't find DT bindings corresponding to DT node used in this > > patch-set. > > > > > Is it not possible to add flexibility in TEE bus enumeration framework to > > > support platform specific properties through OF nodes or ACPI? > > > > > > > TEE bus framework was designed specifically to avoid OF nodes or ACPI > > properties. As devices could be intelligent enough to be queried for > > required properties. > > Is there an expectation that TEE bus enumerated devices to be intelligent? > If so, this is another limitation of TEE bus enumeration. > Please fix these limitations to make TEE bus enumeration > scalable and flexible for future use cases. > It's not a limitation but rather a feature of TEE devices being auto-discoverable rather being described via DT or ACPI. -Sumit > > > > > Devices enumerated by buses such as i2c can read platform specific > > properties. > > > > i2c devices are real hardware which could be platform agnostic, so you > > need to have platform specific properties. > > > > -Sumit > > > > > With this flexibility added, more future use cases through TEE bus. > > > > > > > > > > This is something similar to what I used in > > > > optee-rng [1] driver to fetch RNG properties. > > > > > > > > [1] > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co > > > > > > m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fchar%2Fhw_random%2Foptee- > > > > > > rng.c%23L176&data=02%7C01%7Cthiruan%40microsoft.com%7Cd37438eaf4f9483e4 > > > > > > 0c708d6d9ccfe0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63693587179549 > > > > > > 3006&sdata=As9sC45Bl7sZdJKOq0sHz6GmXttMxS80Nn5yvN4vqng%3D&reserved= > > > > 0 > > > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Thanks, > > > > > > > Sasha
From: "Sasha Levin (Microsoft)" <sashal@kernel.org> Changes since v2: - Drop the devicetree bindings patch (we don't add any new ones). - More code cleanups based on Jason Gunthorpe's review. Sasha Levin (2): ftpm: firmware TPM running in TEE ftpm: add documentation for ftpm driver Documentation/security/tpm/index.rst | 1 + Documentation/security/tpm/tpm_ftpm_tee.rst | 31 ++ drivers/char/tpm/Kconfig | 5 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 366 ++++++++++++++++++++ drivers/char/tpm/tpm_ftpm_tee.h | 47 +++ 6 files changed, 451 insertions(+) create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h