| Message ID | 20230305022119.1331495-4-luzmaximilian@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | firmware: Add support for Qualcomm UEFI Secure Application | expand |
On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: > Add bindings for the Qualcomm Secure Execution Environment interface > (QSEECOM). Pretty sure I already asked, but no answer in the commit message. Why do we need this? You've already declared the platform supports SCM calls with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT is for non-discoverable h/w we are stuck with. Why is software made non-discoverable too? Nodes with only a compatible string are usually just an abuse of DT to instantiate some driver. Rob
On 3/8/23 23:16, Rob Herring wrote: > On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >> Add bindings for the Qualcomm Secure Execution Environment interface >> (QSEECOM). > > Pretty sure I already asked, but no answer in the commit message. Why do > we need this? You've already declared the platform supports SCM calls > with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT > is for non-discoverable h/w we are stuck with. Yes, you've asked this before but I can only repeat what I've written in my last response to your question: I am not aware of any way to properly discover the interface at runtime from software. If it makes you happy, I can put this in the commit message as well... > Why is software made non-discoverable too? Please direct that question at the Qualcomm guys who actually designed that interface. I can't give you an answer to that, and I'm not all that happy about this either. To reiterate: I've reverse engineered this based on the Windows driver. The Windows driver loads on an ACPI HID and it doesn't use any function to check/verify whether the interface is actually present. Adding a DT entry is the straight-forward adaption to having a HID in ACPI. > Nodes with only a compatible string are usually just an abuse of DT to > instantiate some driver. If you or anyone here has any idea on how to discover the presence of this, please feel free to let me know and I'd be happy to implement that. Until then, I unfortunately don't see any other way of dealing with this. Regards, Max
On 09/03/2023 00:44, Maximilian Luz wrote: > On 3/8/23 23:16, Rob Herring wrote: >> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>> Add bindings for the Qualcomm Secure Execution Environment interface >>> (QSEECOM). >> >> Pretty sure I already asked, but no answer in the commit message. Why do >> we need this? You've already declared the platform supports SCM calls >> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >> is for non-discoverable h/w we are stuck with. > > Yes, you've asked this before but I can only repeat what I've written in > my last response to your question: I am not aware of any way to properly > discover the interface at runtime from software. > > If it makes you happy, I can put this in the commit message as well... > >> Why is software made non-discoverable too? > > Please direct that question at the Qualcomm guys who actually designed > that interface. I can't give you an answer to that, and I'm not all that > happy about this either. > > To reiterate: I've reverse engineered this based on the Windows driver. > The Windows driver loads on an ACPI HID and it doesn't use any function > to check/verify whether the interface is actually present. Adding a DT > entry is the straight-forward adaption to having a HID in ACPI. > >> Nodes with only a compatible string are usually just an abuse of DT to >> instantiate some driver. > > If you or anyone here has any idea on how to discover the presence of > this, please feel free to let me know and I'd be happy to implement > that. Until then, I unfortunately don't see any other way of dealing > with this. You can probably try requesting QSEECOM version. According to msm-3.18: uint32_t feature = 10; rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), &resp, sizeof(resp)); pr_info("qseecom.qsee_version = 0x%x\n", resp.result); if (rc) { pr_err("Failed to get QSEE version info %d\n", rc); goto exit_del_cdev; }
On 3/9/23 02:33, Dmitry Baryshkov wrote: > On 09/03/2023 00:44, Maximilian Luz wrote: >> On 3/8/23 23:16, Rob Herring wrote: >>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>>> Add bindings for the Qualcomm Secure Execution Environment interface >>>> (QSEECOM). >>> >>> Pretty sure I already asked, but no answer in the commit message. Why do >>> we need this? You've already declared the platform supports SCM calls >>> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >>> is for non-discoverable h/w we are stuck with. >> >> Yes, you've asked this before but I can only repeat what I've written in >> my last response to your question: I am not aware of any way to properly >> discover the interface at runtime from software. >> >> If it makes you happy, I can put this in the commit message as well... >> >>> Why is software made non-discoverable too? >> >> Please direct that question at the Qualcomm guys who actually designed >> that interface. I can't give you an answer to that, and I'm not all that >> happy about this either. >> >> To reiterate: I've reverse engineered this based on the Windows driver. >> The Windows driver loads on an ACPI HID and it doesn't use any function >> to check/verify whether the interface is actually present. Adding a DT >> entry is the straight-forward adaption to having a HID in ACPI. >> >>> Nodes with only a compatible string are usually just an abuse of DT to >>> instantiate some driver. >> >> If you or anyone here has any idea on how to discover the presence of >> this, please feel free to let me know and I'd be happy to implement >> that. Until then, I unfortunately don't see any other way of dealing >> with this. > > You can probably try requesting QSEECOM version. According to msm-3.18: > > uint32_t feature = 10; > > rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), > &resp, sizeof(resp)); > pr_info("qseecom.qsee_version = 0x%x\n", resp.result); > if (rc) { > pr_err("Failed to get QSEE version info %d\n", rc); > goto exit_del_cdev; > } > Thanks! I'll give that a try. As I can't test this on a device that doesn't have qseecom, it would probably be a good idea if someone could test this on a device that has qcom_scm but no qseecom (if those even exist) to make sure this doesn't misbehave. Regards, Max
On 09/03/2023 04:27, Maximilian Luz wrote: > On 3/9/23 02:33, Dmitry Baryshkov wrote: >> On 09/03/2023 00:44, Maximilian Luz wrote: >>> On 3/8/23 23:16, Rob Herring wrote: >>>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>>>> Add bindings for the Qualcomm Secure Execution Environment interface >>>>> (QSEECOM). >>>> >>>> Pretty sure I already asked, but no answer in the commit message. >>>> Why do >>>> we need this? You've already declared the platform supports SCM calls >>>> with "qcom,scm". Why can't you probe whether you have QSEECOM or >>>> not? DT >>>> is for non-discoverable h/w we are stuck with. >>> >>> Yes, you've asked this before but I can only repeat what I've written in >>> my last response to your question: I am not aware of any way to properly >>> discover the interface at runtime from software. >>> >>> If it makes you happy, I can put this in the commit message as well... >>> >>>> Why is software made non-discoverable too? >>> >>> Please direct that question at the Qualcomm guys who actually designed >>> that interface. I can't give you an answer to that, and I'm not all that >>> happy about this either. >>> >>> To reiterate: I've reverse engineered this based on the Windows driver. >>> The Windows driver loads on an ACPI HID and it doesn't use any function >>> to check/verify whether the interface is actually present. Adding a DT >>> entry is the straight-forward adaption to having a HID in ACPI. >>> >>>> Nodes with only a compatible string are usually just an abuse of DT to >>>> instantiate some driver. >>> >>> If you or anyone here has any idea on how to discover the presence of >>> this, please feel free to let me know and I'd be happy to implement >>> that. Until then, I unfortunately don't see any other way of dealing >>> with this. >> >> You can probably try requesting QSEECOM version. According to msm-3.18: >> >> uint32_t feature = 10; >> >> rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), >> &resp, sizeof(resp)); >> pr_info("qseecom.qsee_version = 0x%x\n", resp.result); >> if (rc) { >> pr_err("Failed to get QSEE version info %d\n", rc); >> goto exit_del_cdev; >> } >> > > Thanks! I'll give that a try. > > As I can't test this on a device that doesn't have qseecom, it would > probably be a good idea if someone could test this on a device that has > qcom_scm but no qseecom (if those even exist) to make sure this doesn't > misbehave. I could not find a vendor dts which doesn't have the qseecom device (checked the source trees from 3.4 to the latest revisions).
On 3/9/23 09:19, Dmitry Baryshkov wrote: > On 09/03/2023 04:27, Maximilian Luz wrote: >> On 3/9/23 02:33, Dmitry Baryshkov wrote: >>> On 09/03/2023 00:44, Maximilian Luz wrote: >>>> On 3/8/23 23:16, Rob Herring wrote: >>>>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>>>>> Add bindings for the Qualcomm Secure Execution Environment interface >>>>>> (QSEECOM). >>>>> >>>>> Pretty sure I already asked, but no answer in the commit message. Why do >>>>> we need this? You've already declared the platform supports SCM calls >>>>> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >>>>> is for non-discoverable h/w we are stuck with. >>>> >>>> Yes, you've asked this before but I can only repeat what I've written in >>>> my last response to your question: I am not aware of any way to properly >>>> discover the interface at runtime from software. >>>> >>>> If it makes you happy, I can put this in the commit message as well... >>>> >>>>> Why is software made non-discoverable too? >>>> >>>> Please direct that question at the Qualcomm guys who actually designed >>>> that interface. I can't give you an answer to that, and I'm not all that >>>> happy about this either. >>>> >>>> To reiterate: I've reverse engineered this based on the Windows driver. >>>> The Windows driver loads on an ACPI HID and it doesn't use any function >>>> to check/verify whether the interface is actually present. Adding a DT >>>> entry is the straight-forward adaption to having a HID in ACPI. >>>> >>>>> Nodes with only a compatible string are usually just an abuse of DT to >>>>> instantiate some driver. >>>> >>>> If you or anyone here has any idea on how to discover the presence of >>>> this, please feel free to let me know and I'd be happy to implement >>>> that. Until then, I unfortunately don't see any other way of dealing >>>> with this. >>> >>> You can probably try requesting QSEECOM version. According to msm-3.18: >>> >>> uint32_t feature = 10; >>> >>> rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), >>> &resp, sizeof(resp)); >>> pr_info("qseecom.qsee_version = 0x%x\n", resp.result); >>> if (rc) { >>> pr_err("Failed to get QSEE version info %d\n", rc); >>> goto exit_del_cdev; >>> } >>> >> >> Thanks! I'll give that a try. >> >> As I can't test this on a device that doesn't have qseecom, it would >> probably be a good idea if someone could test this on a device that has >> qcom_scm but no qseecom (if those even exist) to make sure this doesn't >> misbehave. > > I could not find a vendor dts which doesn't have the qseecom device (checked the source trees from 3.4 to the latest revisions). > Thanks for checking! So that only leaves one potential issue: The re-entrant/blocking calls not being handled at the moment. If we detect qseecom based on the version and then try to query the app ID, we could get some devices that use those. I'm not sure what the consequences there are, i.e. if we're potentially blocking something else if one of those calls blocks on such devices. Is there any way we can detect this beforehand? The current proposal isn't very good at handling that either as it assumes that this depends on the SoC generation (which it probably doesn't). So I guess one possibility is to make the list of app-names to be checked SoC specific as well. That at least limits the scope somewhat. Maybe you have some other ideas? Regards, Max
On Thu, 9 Mar 2023 at 22:34, Maximilian Luz <luzmaximilian@gmail.com> wrote: > > On 3/9/23 09:19, Dmitry Baryshkov wrote: > > On 09/03/2023 04:27, Maximilian Luz wrote: > >> On 3/9/23 02:33, Dmitry Baryshkov wrote: > >>> On 09/03/2023 00:44, Maximilian Luz wrote: > >>>> On 3/8/23 23:16, Rob Herring wrote: > >>>>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: > >>>>>> Add bindings for the Qualcomm Secure Execution Environment interface > >>>>>> (QSEECOM). > >>>>> > >>>>> Pretty sure I already asked, but no answer in the commit message. Why do > >>>>> we need this? You've already declared the platform supports SCM calls > >>>>> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT > >>>>> is for non-discoverable h/w we are stuck with. > >>>> > >>>> Yes, you've asked this before but I can only repeat what I've written in > >>>> my last response to your question: I am not aware of any way to properly > >>>> discover the interface at runtime from software. > >>>> > >>>> If it makes you happy, I can put this in the commit message as well... > >>>> > >>>>> Why is software made non-discoverable too? > >>>> > >>>> Please direct that question at the Qualcomm guys who actually designed > >>>> that interface. I can't give you an answer to that, and I'm not all that > >>>> happy about this either. > >>>> > >>>> To reiterate: I've reverse engineered this based on the Windows driver. > >>>> The Windows driver loads on an ACPI HID and it doesn't use any function > >>>> to check/verify whether the interface is actually present. Adding a DT > >>>> entry is the straight-forward adaption to having a HID in ACPI. > >>>> > >>>>> Nodes with only a compatible string are usually just an abuse of DT to > >>>>> instantiate some driver. > >>>> > >>>> If you or anyone here has any idea on how to discover the presence of > >>>> this, please feel free to let me know and I'd be happy to implement > >>>> that. Until then, I unfortunately don't see any other way of dealing > >>>> with this. > >>> > >>> You can probably try requesting QSEECOM version. According to msm-3.18: > >>> > >>> uint32_t feature = 10; > >>> > >>> rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), > >>> &resp, sizeof(resp)); > >>> pr_info("qseecom.qsee_version = 0x%x\n", resp.result); > >>> if (rc) { > >>> pr_err("Failed to get QSEE version info %d\n", rc); > >>> goto exit_del_cdev; > >>> } > >>> > >> > >> Thanks! I'll give that a try. > >> > >> As I can't test this on a device that doesn't have qseecom, it would > >> probably be a good idea if someone could test this on a device that has > >> qcom_scm but no qseecom (if those even exist) to make sure this doesn't > >> misbehave. > > > > I could not find a vendor dts which doesn't have the qseecom device (checked the source trees from 3.4 to the latest revisions). > > > > Thanks for checking! > > So that only leaves one potential issue: The re-entrant/blocking calls > not being handled at the moment. If we detect qseecom based on the > version and then try to query the app ID, we could get some devices that > use those. > > I'm not sure what the consequences there are, i.e. if we're potentially > blocking something else if one of those calls blocks on such devices. Is > there any way we can detect this beforehand? Unfortunately I don't know. > > The current proposal isn't very good at handling that either as it > assumes that this depends on the SoC generation (which it probably > doesn't). So I guess one possibility is to make the list of app-names to > be checked SoC specific as well. That at least limits the scope > somewhat. Maybe you have some other ideas? As long as it doesn't concern the external interfaces, it sounds fine with me. Let's get the first implementation in, then we can expand and extend the details/implementation.
On 08/03/2023 23:44, Maximilian Luz wrote: > On 3/8/23 23:16, Rob Herring wrote: >> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>> Add bindings for the Qualcomm Secure Execution Environment interface >>> (QSEECOM). >> >> Pretty sure I already asked, but no answer in the commit message. Why do >> we need this? You've already declared the platform supports SCM calls >> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >> is for non-discoverable h/w we are stuck with. > > Yes, you've asked this before but I can only repeat what I've written in > my last response to your question: I am not aware of any way to properly > discover the interface at runtime from software. > > If it makes you happy, I can put this in the commit message as well... Yes, please, because commit msg should answer to "why we are doing this", when this is not obvious. If the reviewer asks the same twice it means it is not obvious. > >> Why is software made non-discoverable too? > > Please direct that question at the Qualcomm guys who actually designed > that interface. I can't give you an answer to that, and I'm not all that > happy about this either. > > To reiterate: I've reverse engineered this based on the Windows driver. > The Windows driver loads on an ACPI HID and it doesn't use any function > to check/verify whether the interface is actually present. Adding a DT > entry is the straight-forward adaption to having a HID in ACPI. Best regards, Krzysztof
On 5/2/23 10:38, Sudeep Holla wrote: > On Thu, Mar 09, 2023 at 03:27:01AM +0100, Maximilian Luz wrote: >> On 3/9/23 02:33, Dmitry Baryshkov wrote: >>> On 09/03/2023 00:44, Maximilian Luz wrote: >>>> On 3/8/23 23:16, Rob Herring wrote: >>>>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>>>>> Add bindings for the Qualcomm Secure Execution Environment interface >>>>>> (QSEECOM). >>>>> >>>>> Pretty sure I already asked, but no answer in the commit message. Why do >>>>> we need this? You've already declared the platform supports SCM calls >>>>> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >>>>> is for non-discoverable h/w we are stuck with. >>>> >>>> Yes, you've asked this before but I can only repeat what I've written in >>>> my last response to your question: I am not aware of any way to properly >>>> discover the interface at runtime from software. >>>> >>>> If it makes you happy, I can put this in the commit message as well... >>>> >>>>> Why is software made non-discoverable too? >>>> >>>> Please direct that question at the Qualcomm guys who actually designed >>>> that interface. I can't give you an answer to that, and I'm not all that >>>> happy about this either. >>>> >>>> To reiterate: I've reverse engineered this based on the Windows driver. >>>> The Windows driver loads on an ACPI HID and it doesn't use any function >>>> to check/verify whether the interface is actually present. Adding a DT >>>> entry is the straight-forward adaption to having a HID in ACPI. >>>> >>>>> Nodes with only a compatible string are usually just an abuse of DT to >>>>> instantiate some driver. >>>> >>>> If you or anyone here has any idea on how to discover the presence of >>>> this, please feel free to let me know and I'd be happy to implement >>>> that. Until then, I unfortunately don't see any other way of dealing >>>> with this. >>> >>> You can probably try requesting QSEECOM version. According to msm-3.18: >>> >>> uint32_t feature = 10; >>> >>> rc = qseecom_scm_call(6, 3, &feature, sizeof(feature), >>> &resp, sizeof(resp)); >>> pr_info("qseecom.qsee_version = 0x%x\n", resp.result); >>> if (rc) { >>> pr_err("Failed to get QSEE version info %d\n", rc); >>> goto exit_del_cdev; >>> } >>> >> >> Thanks! I'll give that a try. >> >> As I can't test this on a device that doesn't have qseecom, it would >> probably be a good idea if someone could test this on a device that has >> qcom_scm but no qseecom (if those even exist) to make sure this doesn't >> misbehave. >> > > TBH, this has been going in round for quite sometime. We have been asking > you to depend on existing platform compatible + a query or a check on the > version. Since you do have a platform that is working, we can start making > it min "qseecom.qsee_version" supported and then adjust the version based > on the testing or the requirement. What do you think ? Sure, I will add a minimum version check to that. Regards, Max
On 5/2/23 10:31, Krzysztof Kozlowski wrote: > On 08/03/2023 23:44, Maximilian Luz wrote: >> On 3/8/23 23:16, Rob Herring wrote: >>> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote: >>>> Add bindings for the Qualcomm Secure Execution Environment interface >>>> (QSEECOM). >>> >>> Pretty sure I already asked, but no answer in the commit message. Why do >>> we need this? You've already declared the platform supports SCM calls >>> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT >>> is for non-discoverable h/w we are stuck with. >> >> Yes, you've asked this before but I can only repeat what I've written in >> my last response to your question: I am not aware of any way to properly >> discover the interface at runtime from software. >> >> If it makes you happy, I can put this in the commit message as well... > > Yes, please, because commit msg should answer to "why we are doing > this", when this is not obvious. If the reviewer asks the same twice it > means it is not obvious. Thanks. Hopefully I can manage to tie that (reliably) to qcom,scm and we don't need the specific compatible for v4 any more. I will try to be more descriptive for the next set of patches though. Regards, Max
diff --git a/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml b/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml new file mode 100644 index 000000000000..540a604f81bc --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/qcom,qseecom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Secure Execution Environment Communication Interface + +maintainers: + - Maximilian Luz <luzmaximilian@gmail.com> + +description: | + QSEECOM provides an interface to Qualcomm's Secure Execution Environment + (SEE) running in the Trust Zone via SCM calls. In particular, it allows + communication with secure applications running therein. + + Applications running in this environment can, for example, include + 'uefisecapp', which is required for accessing UEFI variables on certain + systems as these cannot be accessed directly. + +properties: + compatible: + items: + - enum: + - qcom,qseecom-sc8280xp + - const: qcom,qseecom + + qcom,scm: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + A phandle pointing to the QCOM SCM device (see ./qcom,scm.yaml). + +required: + - compatible + - qcom,scm + +additionalProperties: false + +examples: + - | + firmware { + scm { + compatible = "qcom,scm-sc8280xp", "qcom,scm"; + }; + qseecom { + compatible = "qcom,qseecom-sc8280xp", "qcom,qseecom"; + qcom,scm = <&scm>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 1545914a592c..ef1f806986e9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17384,6 +17384,7 @@ QUALCOMM SECURE EXECUTION ENVIRONMENT COMMUNICATION DRIVER M: Maximilian Luz <luzmaximilian@gmail.com> L: linux-arm-msm@vger.kernel.org S: Maintained +F: Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml F: drivers/firmware/qcom_qseecom.c F: include/linux/firmware/qcom/qcom_qseecom.h
Add bindings for the Qualcomm Secure Execution Environment interface (QSEECOM). Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> --- Changes in v3: - None. Changes in v2: - Replaces uefisecapp bindings. - Fix various dt-checker complaints. --- .../bindings/firmware/qcom,qseecom.yaml | 49 +++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/qcom,qseecom.yaml