Re: [tpmdd-devel] tpm: read burstcount from TPM_STS in one 32-bit transaction
On Tue, Jul 25, 2017 at 10:36:11AM -0700, James Bottomley wrote:
> On Tue, 2017-07-25 at 15:04 +0200, Michal Suchánek wrote:
> > Hello,
> >
> > in commit 9754d45e9970 ("tpm: read burstcount from TPM_STS in one
> > 32-bit transaction") you change reading of two 8-bit values to one
> > 32bit read. This is obviously wrong wrt endianess unless the
> > underlying tpm_tis_read32 does endian conversion.
>
> Some of the bus read primitives do do endianness conversions. The
> problem is with the SPI attachment, which has unclear endianness. A
> standard PCI bus attachment uses ioread32() which automatically
> transforms from a little endian bus to the cpu endianness, however SPI
> is forced to transfer the bytes one at a time over the serial bus and
> then transform. The assumption seems to be that the TIS TPM is
> replying in little endian format when SPI connected.
>
> We can probably get the PPC people to confirm this, I believe they have
> a SPI attached TPM.
All the current OpenPOWER hardware designs I'm aware of have the TPM on
I2C. Trusted Computing support in OpenPOWER firmware depends on it
being on I2C.
>
> James
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> tpmdd-devel mailing list
> tpmdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver
On Wed, Jul 27, 2016 at 10:31:52AM -0600, Jason Gunthorpe wrote: > On Wed, Jul 27, 2016 at 11:05:14AM -0500, George Wilson wrote: > > > > Yes, generally Linux expects DT to be set correctly by the boot > > > firmware. Early firmware needs to know the TPM type anyhow to do the > > > TPM setup, so this doesn't seem like a realistic scenario. > > > > A reset is required after upgrade/downgrade. But the version still > > needs to be detected by the firmware somehow. It could be configured > > manually in firmware state after the upgrade/downgrade to properly set > > the property, which seems much less desirable than a probe. > > Well, the firmware has to take care of this. If the firmware wants to > support switchable firmware it needs to be able to do probe that works > with all the firmware versions. > > ACPI and DT both expect the TPM version to be passed to the OS, it is > up to the firmware to do that correctly.. > > The fact you've already seen TPM2 probing failures makes me very > reluctant to turn it on more broadly, and maybe even think we should > get rid of it from tis too.. Cool, that clarifies it precisely: the expectation is that firmware will do any necessary probing and pass the property up in the device tree. All drivers supporting OF must use the data property as a flag for 2.0 for models capable of 2.0 function. > > Jason > -- George Wilson IBM Linux Technology Center Security Development -- ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver
On Tue, Jul 26, 2016 at 03:03:44PM -0600, Jason Gunthorpe wrote: > On Tue, Jul 26, 2016 at 03:39:02PM -0500, George Wilson wrote: > > > Generally speaking probing is somewhat discouraged, currently we only > > > probe for PC platform tis (and even that might be a mistake), all > > > other drivers are designed to be explicit. > > > > How should field upgradable/downgradable TPMs be handled since hardcoding > > the version in the device tree might give the wrong answer? Would early > > firmware be expected to probe nonetheless and set the right device tree > > property? > > Is that a real thing? Yep, it's a thing. I know of at least 2 parts from 2 different suppliers that are field upgradable/downgradable. > > Yes, generally Linux expects DT to be set correctly by the boot > firmware. Early firmware needs to know the TPM type anyhow to do the > TPM setup, so this doesn't seem like a realistic scenario. A reset is required after upgrade/downgrade. But the version still needs to be detected by the firmware somehow. It could be configured manually in firmware state after the upgrade/downgrade to properly set the property, which seems much less desirable than a probe. > > For TPM we made a somewhat arbitary choice that TPM2 has to be > explicit. If there are real systems that benefit from auto-probing it > could be revisited.. I think it's as necessary - at least at the firmware level - as for x86_64. > > But, to be honest, I'm not certain how robust our probe technique is, > and I think we should avoid probing, since TCG didn't design an > approved detection sequence (??). We did see issues with some older 1.2 TPMs that hung when probed by the kernel with the wrong device driver but that hasn't been an issue for some time. It looks like UEFI ultimately does probe and likely that's required for other platforms. I don't think it's safe to assume a TPM is always loaded with a particular firmware version across hard resets. > > Jason > -- George Wilson IBM Linux Technology Center Security Development -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver
On Tue, Jul 26, 2016 at 02:17:11PM -0600, Jason Gunthorpe wrote:
> On Tue, Jul 26, 2016 at 11:44:43PM +0530, Nayna wrote:
> > I got these questions while testing some TPM2.0 stuff using the kernel
> > code from repo having this patch and am using Nuvoton TPM.
> >
> > #1. It seems that support is added only for following device-ids.
> > {.compatible = "nuvoton,npct501"},
> > {.compatible = "winbond,wpct301"},
> > {.compatible = "nuvoton,npct601", .data = OF_IS_TPM2},
> >
> > So, was wondering about why device id nuvoton,npct650 wasn't added for
> > the support ?
>
> Yes, that was the device ID list for Nuvoton.
>
> It is convention in device tree to include older device IDs if the
> device is compatible.
>
> So you might do
>
> compatible = "nuvoton,npct650", "nuvoton,npct601"
>
> Andrew, is 601 even the right name?
>
> > Was it expected to work with some wild-card type device-id as specified
> > in the first line of description comment of file i.e. npct6XX. ?
>
> No.
>
> > So, why is there hard-coded checking and not using tpm2_probe() method
> > which is itself based on direct TPM hardware response for setting the
> > TPM2 flag. ? Is there something I am missing in the design which
> > mandates to have .data set as OF_IS_TPM2.
>
> Generally speaking probing is somewhat discouraged, currently we only
> probe for PC platform tis (and even that might be a mistake), all
> other drivers are designed to be explicit.
How should field upgradable/downgradable TPMs be handled since hardcoding
the version in the device tree might give the wrong answer? Would early
firmware be expected to probe nonetheless and set the right device tree
property?
>
> Jason
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> ___
> tpmdd-devel mailing list
> tpmdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>
--
George Wilson
IBM Linux Technology Center
Security Development
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
