On Mon, Apr 20, 2020 at 05:24:21PM +0200, François Ozog wrote:
> On Mon, 20 Apr 2020 at 15:50, Achin Gupta <achin.gupta@arm.com> wrote:
> >
> > On Mon, Apr 20, 2020 at 03:37:23PM +0200, François Ozog wrote:
> > > On Mon, 20 Apr 2020 at 15:27, Achin Gupta <[1]achin.gupta@arm.com>
> > > wrote:
> > >
> > > Hi Francois,
> > > On Mon, Apr 20, 2020 at 11:45:02AM +0000, Fran�ois Ozog via TF-A
> > > wrote:
> > > > Hi,
> > > >
> > > > I am trying to identify a mechanism to enforce a form of two-way
> > > > isolation between BL33 runtime services in OS, for instance:
> > > > - a pair of 2MB areas that could be RO by one entity and RW by the
> > > other
> > > > - an execute only BL33 2MB area?
> > > Stupid Q! Are you referring to isolation between EFI runtime
> > > services and the
> > > OS?
> > > It is not clear what you mean by BL33 runtime services?
> > >
> > > Not a stupid Q. I concentrate effectively on EFI runtime but more
> > > generally this is the non-trusted firmware component that delivers
> > > runtime services to OS.
> > > (My flow is somewhat convoluted: TFA loads minimal Linux as BL33, Linux
> > > kexecs a UEFI reduced U-Boot (without drivers) which bootefi the
> > > distro).
> >
> > Thanks! I see and IIUC, this is about two separately provisioned SW components
> > that share an EL (EL1 in this case) at the same time in the same image. We want
> > component A to have permission X on a memory region and component B to have
> > permission Y on the same memory region. If so, then this would require a
> > cooperation between the two components?
> >
> Yes. Well cooperation is what happens today: Component A (UEFI
> compliant FW) tells component B not to use memory it occupies.
> I wish an EL(+n) component to make that a guarantee. Yet I don't want
> to have "virtualization".
>
> > I might be still missing the obvious but I am wondering how a SW entity at a
> > higher EL (Hypervisor in EL2 or TF-A in EL3) could create and enforce the
> > separation between the two components. It would not have visibility of what is
> > happening inside the EL at the very least.
>
> I hoped that by installing a page mapping "power play", we could
> enforce some policy.
> Performance here is not important because those data and context
> changes seldomly happen.
> I assume components A and B have a different mapping for the same
> "physical page":
> - EL1_A(VA)-> IA1; EL1_B(VA)->IA2
> - EL2(IA1) -> PA (RW), EL2(IA2)->PA(RO) or "not present"
> A collaboration between UEFI FW and EL2/3 would allow that to happen.
> A call to UEFI runtime service from SystemTable would result in a swap
> of TTBR1 (from EL1_B to EL1_A) so that execution can continue in UEFI.
> (I have no solution, just trying to check if we can find one).
IMO, the fundamental issue is that EFI runtime services have to share the EL
with the OS. This is not a good idea.
The TTBR1 swap is effectively a context switch. The above design choice means
that the switch is into the same blob of the OS and FW image.
It looks like that runtime services need a separate sandbox of their own. Any
other solution is likely to be bespoke and not scalable as it would require
exposing internals of the OS to the higher EL e.g. can EL2/EL3 do the TTBR1 swap
transparently from the OS perspective in all cases?
If performance is not a priority, then has the approach of migrating the backend
of EFI runtime services to one or more SPs been considered. We already do this
for authenticated variables to some extent. Would it be possible on Arm
platforms to only leave a runtime firmware stub in the OS that SMCs into the SP
assigned to provide the requested service.
This could be a S-EL0 SP in the absence of virtualization or another EL1 VM if a
Hypervisor is present.
Just thinking aloud!
Thanks for doing that ! This is very quite fruitful.
If we can make the solution architecture agnostic then it is better. Having the UEFI runtime on OP-TEE@Arm or in SMM@Intel may be a solution rather than doing it at EL2 (I agree with Soby, EL3 is not a right place).
Or we could say this works more securely on Arm...
As I play with LinuxBoot, having runtime services is not possible until shifting the services to either EL2 or OP-TEE.
The EL2 option may have an influence on the overall system performance which may make the solution not fit for all use cases.
As you say Achin, as we already have StandAloneMM sitting there, OP-TEE seems to be a much better target.
cheers,
Achin
>
> >
> > cheers,
> > Achin
> >
> > >
> > > cheers,
> > > Achin
> > > >
> > > > This is similar to hypervisor except it only deals with memory, no
> > > > vCPU, no GIC virtualization...
> > > >
> > > > Could EL3 or EL2 install protective mappings ? BL33 could ask
> > > either
> > > > EL2 hypervisor or SecureMonitor to actually install them.
> > > >
> > > > Cordially,
> > > >
> > > > FF
> > > > --
> > > > TF-A mailing list
> > > > [2]TF-A@lists.trustedfirmware.org
> > > > [3]https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> > > confidential and may also be privileged. If you are not the intended
> > > recipient, please notify the sender immediately and do not disclose
> > > the contents to any other person, use it for any purpose, or store
> > > or copy the information in any medium. Thank you.
> > >
> > > --
> > > [uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&export=download]
> > > Fran�ois-Fr�d�ric Ozog | Director Linaro Edge & Fog Computing Group
> > > T: +33.67221.6485
> > > [4]francois.ozog@linaro.org | Skype: ffozog
> > >
> > > References
> > >
> > > 1. mailto:achin.gupta@arm.com
> > > 2. mailto:TF-A@lists.trustedfirmware.org
> > > 3. https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> > > 4. mailto:francois.ozog@linaro.org
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
>
>
> --
> François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.