Re: [PATCH v2 1/3] ftpm: dt-binding: add dts documentation for fTPM driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 09, 2019 at 04:18:29PM -0500, Rob Herring wrote:
On Tue, Apr 9, 2019 at 1:50 PM Sasha Levin <sashal@xxxxxxxxxx> wrote:

The parameters are similar to the ones used by IBM's vTPM and the
various I2C tpm drivers.

Bindings describe h/w (or firmware interfaces in this case), not drivers.


Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
 .../bindings/security/tpm/tpm_ftpm_tee.txt          | 13 +++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt         |  1 +
 2 files changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt

diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt
new file mode 100644
index 000000000000..20fca67a56c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt
@@ -0,0 +1,13 @@
+Required properties:
+- compatible: should be "microsoft,ftpm"
+- linux,sml-base: 64-bit base address of the reserved memory allocated
+                 for the firmware event log
+- linux,sml-size: size of the memory allocated for the firmware event log

Firmware is defining linux specific properties? What if I want to run
BSD? We should use 'reg' here instead.

This is based on already existing code that defines these names, see
tpm_read_log_of() in drivers/char/tpm/eventlog/of.c .

These properties were described similarily by other interfaces (see
Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt or
Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt for example).

We could rename them all if you'd like, I was just trying to follow the
existing code.

What memory is used here? This should be under /reserved-memory if it
is part of "main" memory.

That's my understanding, yes.

Really, I'd prefer to not see this in DT at all. Make the firmware
discoverable. Why repeat the mistakes of non-discoverable h/w in s/w
interfaces? OP-Tee at least has defined a mechanism to enumerate TEE
functions IIRC.

Sadly the firmware already exists as-is on live hardware, there is a
paper describing it back from 2016 and we're stuck having to support
that.

--
Thanks,
Sasha



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux