linux-kernel - Re: [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <312ede16-f0a9-9b9e-a0d6-fb6e37d9f1bb@gmail.com>
Date:   Fri, 2 Sep 2022 15:18:25 +0200
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     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>,
        Sudeep Holla <sudeep.holla@....com>,
        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,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure
 Application

Hi,

On 9/2/22 09:26, Sumit Garg wrote:
> Hi Maximilian,
> 
> On 02/08/22 18:52, Maximilian Luz wrote:

[...]

>> Thanks for this information! So as far as I understand it, this is currently an
>> interface to user-space only, i.e. does not allow in-kernel drivers for apps?
> 
> The Linux TEE framework already provides an in-kernel interface to TEE as well via TEE bus [1]. There are already multiple kernel drivers [2] [3] [4] [5] [6] [7] using it. So an EFI driver can be an addition to that.
> 
> Now coming on to TEE implementations, the drivers I mentioned are based on OP-TEE where devices are queried/enumerated during OP-TEE probe here [8]. So in similar manner QTEE smcinvoke driver should be able to register devices on the TEE bus.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/staging/tee.rst#n56
> 
> [2] drivers/char/tpm/tpm_ftpm_tee.c
> 
> [3] drivers/char/hw_random/optee-rng.c
> 
> [4] drivers/firmware/arm_scmi/optee.c
> 
> [5] security/keys/trusted-keys/trusted_tee.c
> 
> [6] drivers/firmware/broadcom/tee_bnxt_fw.c
> 
> [7] drivers/rtc/rtc-optee.c
> 
> [8] drivers/tee/optee/device.c

Thanks for those links!

I think it would indeed be good if we could make it work via that
interface and I guess that should generally be possible. As far as I can
see, the biggest problem might be that the current firmware doesn't seem
to use UUIDs, so I guess we might need to emulate them somehow.

It would be great if someone with some actual knowledge of the firmware
used on those devices could have a look at this and provide some
insights.

My plan for now is to hold off on the UEFI variable driver until we have
a (proper) TEE driver, which unfortunately might be a bit out of my
depth. I'm happy to help out in any way I can though.

Regards,
Max