lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 Jul 2022 17:15:41 +0200 From: Maximilian Luz <luzmaximilian@...il.com> To: Sudeep Holla <sudeep.holla@....com> Cc: Andy Gross <agross@...nel.org>, Bjorn Andersson <bjorn.andersson@...aro.org>, Ard Biesheuvel <ardb@...nel.org>, Konrad Dybcio <konrad.dybcio@...ainline.org>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Steev Klimaszewski <steev@...i.org>, Shawn Guo <shawn.guo@...aro.org>, Cristian Marussi <cristian.marussi@....com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-arm-msm@...r.kernel.org, linux-efi@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client On 7/26/22 16:30, Sudeep Holla wrote: > On Sun, Jul 24, 2022 at 12:49:49AM +0200, Maximilian Luz wrote: >> Add bindings for the Qualcomm Trusted Execution Environment (TrEE) UEFI >> Secure application (uefisecapp) client. >> [...] >> +examples: >> + - | >> + firmware { >> + scm { >> + compatible = "qcom,scm-sc8180x", "qcom,scm"; >> + }; >> + tee-uefisecapp { >> + compatible = "qcom,tee-uefisecapp"; >> + }; > > Do you expect some issues using the scm driver APIs without the > any additions in the DT ? I mean can't you auto-discover by using the > APIs. I haven't looked at the driver or any other patches in the series, > but I would like to know if we can avoid adding any new bindings if it > can be discovered via those SCM driver APIs. Not at scale, at least as far as I can tell. Part of the setup-process of this driver is to query an "application ID" from a unique string identifying the application (in this case "qcom.tz.uefisecapp"). If that call fails, we know the app is not there. But: If we'd want to support more than just "uefisecapp" we'd have to query each app in some predefined list. As far as I can tell, there's no method to enumerate all present/loaded ones. The Windows driver seems to use a hard-coded list of apps that are present on some specific SoC. It might be possible that there exists such a method, but if it does, the Windows driver doesn't seem to use it and I don't know about it. Also, there would need to be at least some type of compatible to indicate the presence of that TrEE / Secure Application interface used by uefisecapp. Unless you want to send some potentially unsupported SCM commands on every platform with qcom,scm and see what comes back. So ultimately I think it's better to add a DT entry for it. That also (hopefully) ensures that someone tested and (at least in some way) validated this. Again, It's a reverse engineered driver. Regards, Max
Powered by blists - more mailing lists