Hex Five’s MultiZone Security for RISC-V

Make it to the Right and Larger Audience


Hex Five’s MultiZone Security for RISC-V

Security has gained lots of attention in today’s microprocessor and SoC Design. Arm provides TrustZone hardware solution and multiple Trusted Execution Environment (TEE) based on TrustZone have been proposed and adopted. RISC-V is an open source ISA and processor project, originated from UCB. It is mostly viewed as a direct competitor of ARM processors. MultiZone from Hex Five is a TEE for RISC-V.


First, what does “security” mean in this context? It basically means firmware isolation and hardware protection. Certain firmware should not interfere with other firmware and should not access certain hardware to protect it from being tampered by malicious firmware. A good reading can be found in Memory Protection. ARM processors provide either MMU or MPU for memory protection. MPU is a trim-down version of MMU and it only provides memory access protection and does not do virtual address translation. Besides memory protection, the MPU can also be used for the following purposes:

  • Disabling the write buffer inside the processor – in some cases, the write buffer inside the processor could make it a bit more difficult to identify software bugs because when a bus fault happen with a buffered write, the processor could have executed a number of instructions before the fault is detected. The MPU can be used to disable the internal write buffer by setting the Bufferable attribute to 0. (Note: You can use the Auxiliary Control Register to achieve this; see section 9.9.)
  • Making a RAM memory space non-executable – in some applications, an external interface (e.g., Ethernet) can inject data into the buffer space allocated in RAM. The data could potentially contain malicious code and if the design contains other vulnerabilities, the malicious code injected into the system could be executed. The MPU can be used to force the RAM space to be eXecute Never (XN), which prevents data injected to the buffer from getting executed.


Here is a brief comparison of TrustZone and MultiZone. TrustZone divides SoC into two worlds, secure zone and non-secure zone. On the contrary, MultiZone supports unlimited number of isolated zones.

MultiZone’s components are:

  • MultiZone™ nanoKernel – lightweight kernel providing policy-driven hardware-enforced separation of ram, rom, i/o and interrupts.
  • InterZone Messenger – communications infrastructure to exchange secure messages across zones on a no- shared memory basis.
  • MultiZone Configurator – combines fully linked zone executables with policies and kernel to generate the signed firmware image.
  • MultiZone Secure Boot – 2-stage secure boot loader to verify integrity and authenticity of the firmware image (sha-256 / ECC)




A presentation of MultiZone is available on youtube:


A more detailed explaination of Multizone is available from its Github repo, https://github.com/hex-five/multizone-sdk/blob/master/manual.pdf


Several questions to be answered.


First, how does this MultiZone is achieved?

This multizone isolation needs to meet the requirement that one zone should not access resources such as memory allocated for another zone. We may say firmware can check the address before making the real access to memory or other hardware. But it is not only inefficient but also not safe. Some malicious code can just do a direct access. Another way is to use RISC-V’s PMP (Physical Memory Protection) unit. PMP can check if an access is allowed. PMP works as MPU in Arm processor. But there is only one PMP and how does it support unlimited number of security zones in MultiZone? Maybe PMP is re-programmed when RISC-V switches context to a new security zone? This is the only way I think can make it work. But Multizone doc says “Up to 32 memory-mapped resources per zone – i.e. flash, ram, i/o, uart, gpio, timers, etc.” while RISC-V PMP supports up to 16 regions. Maybe PMP is expansible by customer design.


Second, what is PMP and PMA in RISC-V?

It is mentioned RISC-V ISA has hooks for security. Looks it refers to PMA, Physical Memory Attributes. RISV-V ISA manual can be found here. Here is the explaination of PMA.


The physical memory map for a complete system includes various address ranges, some corresponding to memory regions, some to memory-mapped control registers, and some to empty holes in the
40 Volume II: RISC-V Privileged Architectures V1.10
address space. Some memory regions might not support reads, writes, or execution; some might
not support subword or subblock accesses; some might not support atomic operations; and some
might not support cache coherence or might have different memory models. Similarly, memorymapped control registers vary in their supported access widths, support for atomic operations, and
whether read and write accesses have associated side effects. In RISC-V systems, these properties
and capabilities of each region of the machine’s physical address space are termed physical memory
attributes (PMAs).

For RISC-V, we separate out specification and checking of PMAs into a separate hardware structure,
the PMA checker. In many cases, the attributes are known at system design time for each physical
address region, and can be hardwired into the PMA checker. Where the attributes are run-time
configurable, platform-specific memory-mapped control registers can be provided to specify these
attributes at a granularity appropriate to each region on the platform (e.g., for an on-chip SRAM
that can be flexibly divided between cacheable and uncacheable uses). PMAs are checked for any
access to physical memory.


Here is about PMP, Physical Memory Protection.

To support secure processing and contain faults, it is desirable to limit the physical addresses
accessible by software running on a hart. An optional physical memory protection (PMP) unit
provides per-hart machine-mode control registers to allow physical memory access privileges (read,
write, execute) to be specified for each physical memory region. The PMP values are checked in
parallel with the PMA checks.


Third, in “RISC-V Privileged Architecture v1.1”, is IOPMP a hardware module at memory and peripheral interface? It makes sense if so. Firmware can program IOPMPs to achieve address access isolation.


Author brief is empty

  1. chieuluu 6 months ago


  2. rao_mallikarjun 11 months ago



Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.


©2020  ValPont.com

Forgot your details?