On 26/07/18 09:42, Sumit Garg wrote:
On Thu, 26 Jul 2018 at 13:20, Daniel Thompson
<[email protected]> wrote:
On Thu, Jul 26, 2018 at 09:39:37AM +0200, Ard Biesheuvel wrote:
On 26 July 2018 at 09:36, Daniel Thompson <[email protected]> wrote:
On Wed, Jul 25, 2018 at 12:04:58PM +0200, Ard Biesheuvel wrote:
On 23 July 2018 at 15:19, Sumit Garg <[email protected]> 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 <[email protected]>
Cc: Leif Lindholm <[email protected]>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sumit Garg <[email protected]>
---
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.
Daniel.
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
