All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Konrad Dybcio <konrad.dybcio@somainline.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Steev Klimaszewski <steev@kali.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-arm-msm@vger.kernel.org, linux-efi@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client
Date: Tue, 26 Jul 2022 19:01:28 +0200	[thread overview]
Message-ID: <d1bc99bb-82ce-aa6e-7fad-e9309fa1c19b@gmail.com> (raw)
In-Reply-To: <20220726154138.74avqs6iqlzqpzjk@bogus>

On 7/26/22 17:41, Sudeep Holla wrote:
> On Tue, Jul 26, 2022 at 05:15:41PM +0200, Maximilian Luz wrote:
>>
>> So ultimately I think it's better to add a DT entry for it.
> 
> I disagree for the reason that once you discover more apps running on the
> secure side, you want to add more entries and update DT on the platform
> every time you discover some new firmware entity and you wish to interact
> with it from the non-secure side.

Just as you'll have to add a driver to the kernel and update whatever is
probing the TrEE interface and add those strings to that interface. If
you then start doing SoC-specific lists, I think you'd be pretty much
re-implementing a DT in the kernel driver...

I don't quite understand why this is a problem. I think per device,
there's a reasonably limited set of apps that we would want to interact
with from the kernel. And for one single device, that set doesn't change
over time. So what's the difference to, say, an I2C device?

> As along as get this application ID can handle any random name, I prefer
> to use that as the discover mechanism and not have this DT.

Apart from the above, some apps must also be loaded from the system. And
those you can't detect: If an app isn't running, it doesn't have an ID
(uefisecapp and the tpm app are loaded by the firmware at boot). Those
are mostly vendor-specific things as far as I can tell, or HDCP stuff.
So you'd need to specify those as firmware somehow, and since (as far as
I can tell) those are signed specifically by/for that vendor and
potentially device (similar to the GPU zap shader or remoteproc
firmware), you'll need to use per-device paths.

That means you either hard-code them in the driver and have a compatible
per model, do DMI matching, or something similar (again, essentially
baking DTs into the kernel driver...), or just store them in the DT
(like we already do for GPU/remoteprocs). While you could hard-code some
known loaded-by-firmware apps and use the DT for others, I think we
should keep everything in the same place.

Windows uses a hard-coded list of supported apps in the driver (to
specify which apps the driver supports) and in addition to that uses
Registry entries (added via .inf files) to specify which app is supposed
to be present on the device and, for apps that need to be loaded, where
the firmware to be loaded is stored. It only ever attempts to connect to
those apps that are marked present in the registry. Which, again, may be
model/vendor specific.

And this is another reason I'm hesitant to use that function: Windows
doesn't use it in this way and that I don't know whether there can be
any subtle breakage or unexpected behavior if we use the function like
that (i.e., who's to say some broken firmware returns "app is present"
but the app is broken?).

Regards,
Max

  reply	other threads:[~2022-07-26 17:01 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-23 22:49 [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application Maximilian Luz
2022-07-23 22:49 ` [PATCH 1/4] firmware: qcom_scm: Export SCM call functions Maximilian Luz
2022-07-23 22:49 ` [PATCH 2/4] firmware: Add support for Qualcomm Trusted Execution Environment SCM calls Maximilian Luz
2022-07-23 22:49 ` [PATCH 3/4] firmware: Add support for Qualcomm UEFI Secure Application Maximilian Luz
2023-01-17  8:24   ` Johan Hovold
2023-01-17  8:42     ` Maximilian Luz
2023-01-18 20:45     ` Maximilian Luz
2023-01-19 16:47       ` Johan Hovold
2023-01-19 17:19         ` Maximilian Luz
2023-01-17 11:05   ` Johan Hovold
2023-01-17 12:07     ` Maximilian Luz
2022-07-23 22:49 ` [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client Maximilian Luz
2022-07-25  1:06   ` Rob Herring
2022-07-26 10:17   ` Krzysztof Kozlowski
2022-07-26 11:15     ` Maximilian Luz
2022-07-26 13:25       ` Krzysztof Kozlowski
2022-07-26 15:00         ` Maximilian Luz
2022-07-27 11:24           ` Krzysztof Kozlowski
2022-07-27 13:00             ` Maximilian Luz
2022-07-28  7:48               ` Krzysztof Kozlowski
2022-07-28 10:25                 ` Maximilian Luz
2022-07-28 10:38                   ` Krzysztof Kozlowski
2022-07-28 10:49                     ` Maximilian Luz
2022-07-26 14:30   ` Sudeep Holla
2022-07-26 15:15     ` Maximilian Luz
2022-07-26 15:41       ` Sudeep Holla
2022-07-26 17:01         ` Maximilian Luz [this message]
2022-07-27 11:38           ` Krzysztof Kozlowski
2022-07-27 13:03             ` Maximilian Luz
2022-07-27 13:24               ` Sudeep Holla
2022-07-27 14:49                 ` Maximilian Luz
2022-07-28  6:03                 ` Ilias Apalodimas
2022-07-28 10:48                   ` Maximilian Luz
2022-07-28 11:33                     ` Sudeep Holla
2022-07-28 12:13                       ` Maximilian Luz
2022-07-28 12:24                       ` Ilias Apalodimas
2022-07-28 15:05                       ` Ard Biesheuvel
2022-07-28 15:16                         ` Ilias Apalodimas
2022-07-28 16:16                         ` Sudeep Holla
2022-07-28 16:24                           ` Konrad Dybcio
2022-07-28 12:35                     ` Ilias Apalodimas
2022-07-28 12:49                       ` Maximilian Luz
2022-07-28 16:56                         ` Ilias Apalodimas
2022-07-28 17:27                           ` Maximilian Luz
2022-07-29  8:52                             ` Sudeep Holla
2022-07-29 15:11                               ` Maximilian Luz
2022-07-31  9:54                             ` Ilias Apalodimas
2022-07-31 22:48                               ` Maximilian Luz
2022-07-28  8:23           ` Sudeep Holla
2022-07-28 10:05             ` Maximilian Luz
2022-07-28 11:21               ` Sudeep Holla
2022-07-28 11:45                 ` Maximilian Luz
2022-07-28 13:42                   ` Sudeep Holla
2022-07-28 14:09                     ` Maximilian Luz
2022-07-25 19:27 ` [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application Rob Herring
2022-07-25 20:16   ` Maximilian Luz
2022-08-02 11:51 ` Srinivas Kandagatla
2022-08-02 13:22   ` Maximilian Luz
2022-08-02 14:02     ` Ard Biesheuvel
2022-08-02 19:11       ` Maximilian Luz
2022-09-02  7:26     ` Sumit Garg
2022-09-02 13:18       ` Maximilian Luz
2022-09-05  6:50         ` Sumit Garg
2022-11-23 11:22     ` Srinivas Kandagatla
2022-11-23 12:05       ` Maximilian Luz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1bc99bb-82ce-aa6e-7fad-e9309fa1c19b@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=agross@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawn.guo@linaro.org \
    --cc=steev@kali.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.