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?
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)?
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?
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
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
tf-a@lists.trustedfirmware.org
-
François Ozog -
Olivier.Deprez＠arm.com