linux-kernel - Re: [Patch V5 2/3] tpm_tis-spi: Support hardware wait polling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y/9xec98YXB/6G11@nvidia.com>
Date:   Wed, 1 Mar 2023 11:38:33 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Krishna Yarlagadda <kyarlagadda@...dia.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "peterhuewe@....de" <peterhuewe@....de>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Sowjanya Komatineni <skomatineni@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>
Subject: Re: [Patch V5 2/3] tpm_tis-spi: Support hardware wait polling

On Wed, Mar 01, 2023 at 03:09:24PM +0100, Thierry Reding wrote:
> On Wed, Mar 01, 2023 at 09:39:28AM -0400, Jason Gunthorpe wrote:
> > On Wed, Mar 01, 2023 at 12:37:27PM +0000, Mark Brown wrote:
> > > On Wed, Mar 01, 2023 at 08:27:45AM -0400, Jason Gunthorpe wrote:
> > > > On Wed, Mar 01, 2023 at 11:56:53AM +0000, Krishna Yarlagadda wrote:
> > > 
> > > > > TPM device connected behind half duplex controller can only work
> > > > > this way. So, no additional flag needed to check.
> > > 
> > > > Just because a DT hooks it up this way doesn't mean the kernel driver
> > > > can support it, eg support hasn't been implemented in an older SPI
> > > > driver or something.
> > > 
> > > > If the failure mode is anything other than the TPM doesn't probe we
> > > > will need to check for support.
> > > 
> > > It's not like these buses are hot pluggable - someone would have to
> > > design and manufacture a board which doesn't work.  It's probably
> > > reasonable for this to fail with the SPI subsystem saying it can't
> > > support things when the operation is tried.
> > 
> > If the spi subsystem fails this request with these flags that would be
> > great, it would cause the TPM to fail probing reliably.
> > 
> > But does this patch do that? It looks like non-supporting half duplex
> > drivers will just ignore the new flag?
> 
> I think the assumption is that there are currently no half duplex
> drivers that would be impacted by this. If I understand correctly, the
> TPM driver currently supports only full duplex controllers, because
> that's required in order to detect the wait state in software.
> 
> So, yes, half duplex controllers would ignore this flag, but since they
> couldn't have supported TPM flow control before anyway it doesn't make a
> difference.

If more HW uses this feature it will likely look a lot like these
tegra drivers where an existing supported SPI driver gains a HW bit to
do the flow. Meaning DTs will exist configuring a TPM to a half duplex
SPI and kernels will exist that don't have the HW driver that
implements it.

So, I would like it if old kernels running against a new DT do not
mis-operate the SPI because their SPI driver does not support TPM
operation. Either because the spi layer refuses the request as
unsupported or the TPM layer refuses to use the spi driver as
unsupported.

I do not like the idea that the SPI subsystem will take a request from
a client driver and silently mis-execute it.

Jason