Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client

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

 



On 7/29/22 10:52, Sudeep Holla wrote:
On Thu, Jul 28, 2022 at 07:27:19PM +0200, Maximilian Luz wrote:

[...]

My current suggestion (already sent to Sudeep earlier) is (roughly)
this: Add one compatible for the TrEE / TrustZone interface.

Still I don't understand why you need extra compatible if you know
this laptop(with a unique compatible to identify it) always runs this
TrEE interface.

First of all, to recap: I suggest adding a device and driver for the TrEE
interface, with a compatible for that. That then (based on platform)
instantiates devices and drivers for the applications running in TrEE. The
compatible I'm talking about is for that general TrEE interface. Not any
specific application.

a) Because this better reflects the ACPI tables on those devices. As I've said,
   there is a HID specifically for the TrEE interface. You were concerned
   earlier that we should try to add support for that, and now you want to
   create a purely artificial divide between ACPI and DT? Ideally, we can have
   the driver load via both the DT compatible and the ACPI HID depending on
   whether we use one or the other without many other changes.

   Would you equally suggest that we not load the driver by its ACPI HID and
   instead do DMI matching?

b) Qualcomm also has a DT compatible for this (qcom,qseecom), see e.g. [1].
   Note: they seem to have changed the name from Secure Execution Environment
   to Trusted Execution Environment, at least in their Windows driver. This is
   why I used "tee" instead of "see" (also their naming of things is somewhat
   confusing and seems to change randomly). Fundamentally, this is the same
   interface (they just implement a lot more things in their driver, the couple
   of functions I proposed here handle the absolute minimum required for
   uefisecapp, it can always be extended later when needed).

c) Given their naming of the DT compatible, this interface itself is pretty
   much guaranteed to be stable. It's definitely not going away with some
   firmware update. So your earlier concerns about having to update the DT in
   case of firmware changes do simply not apply here. It is a core component of
   these platforms. As far as I can see, your "let's load the TrEE driver via
   the platform compatible" suggestion is now exactly the same as a "let's load
   some PCIe controller via the platform/SoC compatible". It's an interface
   that is either present or not present, depending on the device. We're not
   encoding any firmware specifics (ie. what's running inside the TrEE) in the
   DT, we just say that it's there (the rest is decided by the driver, e.g. via
   platform compatibles or DMI matching).

d) By specifying it in the DT, we can properly link it up via a phandle to the
   SCM and properly model the supplier/client relation between them. While we
   can't do that with ACPI, I think it's still a good idea to handle this
   properly in times we can.

Regards,
Max

[1]: https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/auto-kernel.lnx.4.14.c34/drivers/misc/qseecom.c



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux