On 27 July 2018 at 13:37, Sumit Garg <sumit.g...@linaro.org> wrote: > On Fri, 27 Jul 2018 at 16:40, Daniel Thompson > <daniel.thomp...@linaro.org> wrote: >> >> On 26/07/18 09:42, Sumit Garg wrote: >> > On Thu, 26 Jul 2018 at 13:20, Daniel Thompson >> > <daniel.thomp...@linaro.org> wrote: >> >> >> >> On Thu, Jul 26, 2018 at 09:39:37AM +0200, Ard Biesheuvel wrote: >> >>> On 26 July 2018 at 09:36, Daniel Thompson <daniel.thomp...@linaro.org> >> >>> wrote: >> >>>> On Wed, Jul 25, 2018 at 12:04:58PM +0200, Ard Biesheuvel wrote: >> >>>>> On 23 July 2018 at 15:19, Sumit Garg <sumit.g...@linaro.org> wrote: >> >>>>>> OP-TEE is optional on Developerbox controlled via SCP firmware. To >> >>>>>> check >> >>>>>> if we need to delete OP-TEE DT node, we use DRAM1 region info as SCP >> >>>>>> firmware conditionally carves out Secure memory from DRAM1 region. >> >>>>>> >> >>>>>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> >> >>>>>> Cc: Leif Lindholm <leif.lindh...@linaro.org> >> >>>>>> Contributed-under: TianoCore Contribution Agreement 1.1 >> >>>>>> Signed-off-by: Sumit Garg <sumit.g...@linaro.org> >> >>>>>> --- >> >>>>>> >> >>>>> >> >>>>> As discussed on IRC, i am not a fan of inferring the presence of >> >>>>> OP-TEE from the base/size values of the first DRAM region. >> >>>>> >> >>>>> Please refer to the existing PCIe code how to read a GPIO in PEI and >> >>>>> set a dynamic PCD accordingly, so you can use its value in >> >>>>> PlatformDxe. >> >>>> >> >>>> For Trusted Firmware I asked Sumit to look for the OP-TEE memory carve >> >>>> out rather than looking at the switches. This was based on concerns >> >>>> about version skew (new C-A53 firmware, old SCP firmware[1]), in >> >>>> particular >> >>>> if TF-A jumps to an OP-TEE that isn't actually loaded the system will >> >>>> fail in a not very transparent way (especially if the user hasn't found >> >>>> the debug UART behind the back panel yet). >> >>>> >> >>>> What is the consequence of passing a DT with OP-TEE present if one is >> >>>> not actually present? Do we at least get as far as bringing up the >> >>>> framebuffer before things explode? >> >>>> >> > >> > If we pass a DT with OP-TEE and OP-TEE not present, Linux TEE generic >> > driver exits gracefully giving following message: >> > >> > [ 1.976021] optee: probing for conduit method from DT. >> > [ 1.976033] optee: api uid mismatch >> >> That certainly means we can be pretty relaxed about version skew of >> normal world components (since nothing bad happens if thinks get skewed). >> >> >> >>> Is there any way we can let OP-TEE supply a DT overlay? >> >> >> >> I guess it could implement a secure monitor call to provide it. In >> >> fact I find it a rather pleasing approach. However I think it still loops >> >> us round to pretty much the same question as before. Does TF-A "protec >> >> " a normal world that makes an SMC to an OP-TEE that isn't there by >> >> failing the call in a nice way? >> >> >> > >> > TF-A returns SMC call for OP-TEE as unknown (error code: -1 in "x0" >> > register) if OP-TEE is not present. >> >> It is possible to experiment with getting EDK2 to detect OP-TEE using >> SMC? This would be fully generic and presumably be the first step in >> having an EFI OP-TEE driver. >> > > Agree. I will try to detect OP-TEE version via SMC call. If SMC > unknown is returned, then we say OP-TEE is not present and remove > corresponding DT node. > > So I think this EFI OP-TEE driver makes more sense in edk2 rather than > edk2-platforms. >
Indeed. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
