On Mon, 20 Apr 2020 at 14:26, Olivier.Deprez@arm.com wrote:
Hi,
If buffers are to be consumed by NWd only, it's probably better to contain the isolation at NS-EL2 (through Stage-2 MMU mapping).
Though from your statements I'm not clear if you wish to use an hypervisor, or not?
I don't want the cost of a full fledged hypervisor. just the MMU and SMMU control.
If yes, which implementation or kind do you want to use?
If not, I wonder if you could re-use OS facilities like shared mem with different permissions for two child processes (might be tricky)?
The whole idea is to not trust the OS for protecting the FW. I don't think it would make the system more secure but it would clearly implement a boundary. The intent is to ensure that a call to reboot is actually performed, whatever state the OS is (say a bug in a driver that attempts to write on FW memory, triggers an exception while holding a spinlock and the kernel is not fully operational).
I don't think execute-only regions exist in Cortex-A (unless implementing additional hardware). If executable it's probably also readable. Maybe you meant execute-never?
So that would be RO for code also.
Regards, Olivier.
From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of François Ozog via TF-A tf-a@lists.trustedfirmware.org Sent: 20 April 2020 13:45 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] [RFC] isolation between runtime BL33 services and OS
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?
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 TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a