4.13.1 Core MMU, UX/SX bits, and embedded hypervisor
The chip's first line of defense against unintended interactions amongst the multiple CPUs/OSes is each core vCPU's MMU.
A vCPU's MMU is configured to determine which addresses in the global address map the CPU is able to read or write. If a
particular resource (memory region, peripheral device, and so on) is dedicated to a single vCPU, that vCPU's MMU is
configured to allow access to those addresses (on 4 KB granularity); other vCPU MMUs are not configured for access to
those addresses, which makes them private. When two vCPUs need to share resources, their MMUs are both configured so
that they have access to the shared address range.
This level of hardware support for partitioning is common today; however, it is not sufficient for many core systems running
diverse software. When the functions of multiple discrete CPUs are consolidated onto a single multicore chip, achieving
strong partitioning should not require the developer to map functions onto vCPUs that are the exclusive owners of specific
platform resources. The alternative, a fully open system with no private resources, is also unacceptable. For this reason, the
core's MMU also includes three levels of access permissions: user, supervisor (OS), and hypervisor. An embedded hypervisor
(for example, KVM, XEN, QorIQ ecosystem partner hypervisor) runs unobtrusively beneath the various OSes running on the
vCPUs, consuming CPU cycles only when an access attempt is made to an embedded hypervisor-managed shared resource.
The embedded hypervisor determines whether the access should be allowed and, if so, proxies the access on behalf of the
original requestor. If malicious or poorly tested software on any vCPU attempts to overwrite important device configuration
registers (including vCPU's MMU), the embedded hypervisor blocks the write. High and low-speed peripheral interfaces
(PCI Express, UART), when not dedicated to a single vCPU/partition, are other examples of embedded hypervisor managed
resources. The degree of security policy enforcement by the embedded hypervisor is implementation-dependent.
In addition to defining regions of memory as being controlled by the user, supervisor, or hypervisor, the core MMU can also
configure memory regions as being non-executable. Preventing CPUs from executing instructions from regions of memory
used as data buffers is a powerful defense against buffer overflows and other runtime attacks. In previous generations of
Power Architecture, this feature was controlled by the NX (no execute) attribute. In new Power Architecture cores such as
the e6500 core, there are separate bits controlling execution for user (UX) and supervisor (SX).
4.13.2 Peripheral access management unit (PAMU)
MMU-based access control works for software running on CPUs; however, these are not the only bus masters in the SoC.
Internal components with bus mastering capability (FMan, RMan, PCI Express controller, PME, SEC, and so on) also need
to be prevented from reading and writing to certain memory regions. These components do not spontaneously generate access
attempts; however, if programmed to do so by buggy or malicious software, any of them could read or write sensitive data
registers and crash the system. For this reason, the SoC also includes a distributed function referred to as the peripheral
access management unit (PAMU).
PAMUs provide address translation and access control for all non-CPU initiators in the system. PAMU access control is
based on the logical I/O device number (LIODN) advertised by a bus master for a given transaction. LIODNs can be static
(for example, PCI Express controller #1 always uses LIODN 123) or they can be dynamic, based on the ID of the CPU that
programmed the initiator (for example, the SEC uses LIODN 456 because it was given a descriptor by vCPU #2). In the
dynamic example, the SoC architecture provides positive identification of the vCPU programming the SEC, preventing
LIODN spoofing.
4.13.3 IO partitioning
The simplest IO configuration in chips running multiple independent software partitions is to dedicate specific IO controllers
(PCI Express, SATA, Serial RapidIO controllers) to specific vCPUs. The core MMUs and PAMUs can enforce these access
permissions to insure that only the software partition owning the IO is able to use it. The obvious problem with this approach
is that there are likely to be more software partitions wanting IO access than there are IO controllers to dedicate to each.
Chip features
T2080 Product Brief, Rev 0, 04/2014
Freescale Semiconductor, Inc. 21
