On Tue, 2 Aug 2022 at 15:22, Maximilian Luz <luzmaximilian@xxxxxxxxx> wrote: > > > > On 8/2/22 13:51, Srinivas Kandagatla wrote: > > Hi Maximilian, > > > > On 23/07/2022 23:49, Maximilian Luz wrote: > >> On modern Qualcomm platforms, access to EFI variables is restricted to > >> the secure world / TrustZone, i.e. the Trusted Execution Environment > >> (TrEE or TEE) as Qualcomm seems to call it. To access EFI variables, we > >> therefore need to talk to the UEFI Secure Application (uefisecapp), > >> residing in the TrEE. > >> > >> This series adds support for accessing EFI variables on those platforms. > >> > >> To do this, we first need to add some SCM call functions used to manage > >> and talk to Secure Applications. A very small subset of this interface > >> is added in the second patch (whereas the first one exports the required > >> functions for that). Interface specifications are extracted from [1]. > >> While this does not (yet) support re-entrant SCM calls (including > >> callbacks and listeners), this is enough to talk to the aforementioned > >> uefisecapp on a couple of platforms (I've tested this on a Surface Pro X > >> and heard reports from Lenovo Flex 5G, Lenovo Thinkpad x13s, and Lenovo > >> Yoga C630 devices). > >> > >> The third patch adds a client driver for uefisecapp, installing the > >> respective efivar operations. The application interface has been reverse > >> engineered from the Windows QcTrEE8180.sys driver. > >> > >> Apart from uefisecapp, there are more Secure Applications running that > >> we might want to support in the future. For example, on the Surface Pro > >> X (sc8180x-based), the TPM is also managed via one. > >> > >> I'm not sure whether this should go to drivers/firmware or to > >> drivers/soc/qcom. I've put this into firmware as all of this is > >> essentially an interface to the secure firmware running in the TrustZone > >> (and SCM stuff is handled here already), but please let me know if I > >> should move this. > > > > From what I see so far is that this is adapted from downstream qseecom driver, this approach could work for a limited usecases but not scalable, as we cannot add drivers for each Qualcomm specific TA in kernel. > > This has to be handled in much generic way using Linux TEE framework, and let the userspace side deal with TA specific bits. > > I generally agree with the sentiment, however UEFI variables should IMHO be > handled by the kernel. Moving handling of those to userspace breaks things like > EFI-based pstore and efivarfs. The latter will in turn break some user-space > tools (most notably efibootmgr used by e.g. GRUB and I think fwupdmgr which > needs to set some capsule variables). Ideally, we would find a way to not break > these, i.e. have them work out-of-the-box. > Only capsule-on-disk requires SetVariable() at runtime, and I doubt whether these platforms implement any of that. > A similar argumentation might apply to the TPM app. > There is a difference, though - the TPM is modeled as a device and runtime access to it is implemented as a device driver, which is only accessed from user space. > > AFAIU, Qualcomm is moving away from qseecom interface to new smc-invoke interface, most of Qualcomm SoCs starting from SDM660 already have support to this. > > > > This interface provides a better abstracted IPC mechanism to talk to TA. Most of these TA specific interfaces are packed in closed userspace source. > > Having said that QTEE smcinvoke driver can be modeled as a proper TEE driver with Userspace driving the TA specific bits using existing tee uapis. > > This also brings in other features like loading, Listeners aka callbacks, secure memory allocations..etc. > > > > In the past, I have tried to do a prototype of this smcinvoke driver as a proper tee driver, incase you are interested patches are at https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=tracking-qcomlt-qcomtee > > Plan is to discuss with Qualcomm and send it for upstream review. > > 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? > It would be great if this could then be extended to handle (the bare minimum > of) in-kernel drivers (i.e. only things that the kernel itself needs, like EFI > variables). Alternatively, I'm happy to hear suggestions on how we not break > the aforementioned things while moving handling off to userspace. > > > I think its worth exploring if uefisecapp can talk smcinvoke. > > I can ping Qualcomm engineers to see if that is doable. > > I think that would be great! Thanks! > > Regards, > Max
