Re: [TF-A] [RFC] isolation between runtime BL33 services and OS - TF-A

21 Apr 2020

      ...
-----Original Message-----
From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of François
Ozog via TF-A
Sent: 20 April 2020 16:25
To: Achin Gupta Achin.Gupta@arm.com
Cc: tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] [RFC] isolation between runtime BL33 services and OS
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).
HI Francois,
What you suggest is possible AFAICS, as you suggest,  if you create 2 IPAs with corresponding VAs. Communication between the 2 would involve some shared memory and invoking EL2 to trigger the switch between the VAs. This is suited more for an EL2 design I think rather than EL3.
Best Regards
Soby Mathew
...
...
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&amp;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

mailto:achin.gupta@arm.com
mailto:TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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
--
TF-A mailing list
TF-A@lists.trustedfirmware.org
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.