Reason Behind EL2 in non-secured state ARMv8

Hi techguyz,

Simply put, it isn't a reasonable use of processor resources to virtualise the Secure state. The primary use case for the Secure state is to provide trusted services, and these services are usually quite small both for the purposes of security in general (less code means less bugs) and for auditing and certification (to assure there are no holes to your customers). There is already a privilege separation -- EL3, Secure EL1 and Secure EL0 -- which is more than enough to implement that and most other use cases.

While a Hypervisor itself may be quite small and easy to audit (depending on the implementation), the fact that it would probably be able to virtualise any number of arbitrary guest Operating Systems means that all bets are off. The functionality required for virtualisation -- 2nd stage translation regimes, trapping, virtual IRQ and FIQ and so on -- would make the Secure state more complicated and therefore more difficult to assure from a hardware perspective.

Ta,

Matt S.

Hi techguyz,

Simply put, it isn't a reasonable use of processor resources to virtualise the Secure state. The primary use case for the Secure state is to provide trusted services, and these services are usually quite small both for the purposes of security in general (less code means less bugs) and for auditing and certification (to assure there are no holes to your customers). There is already a privilege separation -- EL3, Secure EL1 and Secure EL0 -- which is more than enough to implement that and most other use cases.

While a Hypervisor itself may be quite small and easy to audit (depending on the implementation), the fact that it would probably be able to virtualise any number of arbitrary guest Operating Systems means that all bets are off. The functionality required for virtualisation -- 2nd stage translation regimes, trapping, virtual IRQ and FIQ and so on -- would make the Secure state more complicated and therefore more difficult to assure from a hardware perspective.

Ta,

Matt S.