[Skiboot] [PATCH 3/3] libstb/tpm: block access to unknown i2c devs on the tpm bus

Nayna nayna at linux.vnet.ibm.com
Thu Dec 12 13:14:33 AEDT 2019


On 12/9/19 9:48 PM, Oliver O'Halloran wrote:
> On Tue, Dec 10, 2019 at 12:46 PM Nayna <nayna at linux.vnet.ibm.com> wrote:
>>
>> On 12/3/19 12:46 AM, Oliver O'Halloran wrote:
>>> Our favourite TPM is capable of listening on multiple I2C bus addresses
>>> and although this feature is supposed to be disabled by default we have
>>> some systems in the wild where the TPM appears to be listening on these
>>> secondary addresses.
>>>
>>> The secondary addresses are also susceptible to the bus-lockup problem
>>> that we see with certain traffic patterns to the "main" TPM address.
>>> We don't know what addresses the TPM might be listening on it's best to
>>> take a conservitve approach and only allow traffic to I2C bus addresses
>>> that we are explicitly told about by firmware.
>>>
>>> This is only required on the TPM bus, so this patch extends the existing
>>> TPM workaround to also check that a DT node exists for any I2C bus
>>> address the OS wants to talk to. If there isn't one, we don't forward
>>> the I2C request to the bus and return an I2C timeout error to the OS.
>> I think the userspace will talk to kernel tpm driver, which in turn will
>> talk to Physical TPM via skiboot i2c driver.
>>
>> I don't think the userspace will ever reach the skiboot tpm driver.  I
>> am wondering if the fix has to be handled in the skiboot core i2c driver
>> rather than in tpm_i2c_nuvoton driver.
> The TPM driver sets a quirk callback on the TPM's I2C bus for the I2C
> core to use. When we get an I2C request from the kernel via OPAL call
> the core will allow or block the request based on what the quirk
> functions returns. It's in the right place.

Aah ok.. Sure, thanks for the clarification.

Thanks & Regards,

       - Nayna






More information about the Skiboot mailing list