To get you started, we have developed a few fully functional reference applications based on free and open hardware and software components. All FPGA bitstreams, software and documentation are freely available online at Hex Five’s GitHub repository.

You may want to start with the MultiZone Security SDK and, once confident, move to the more feature-rich  MultiZone Trusted Firmware

MultiZone Security is certified to work with any RISC-V core that has:

• RV32I, RV32E, RV64I architecture (32-bit and 64-bit) compliant with RISC-V Unprivileged ISA 2.1
• ‘U’ extension (User mode) compliant with RISC-V Privileged Architecture 1.11
• At least 4 PMP registers (recommended: 8 for single-core,  16 for multi-core)

The ultimate source of truth for RISC-V extensions is the MISA CSR register. Read this register and look for the bit position equivalent to the letter “U” – position 21.

If it is “1” you can use MultiZone to create unlimited equally secure Trusted Execution Environments.

If it is “0” this core lacks the most basic security block (PMP) and it is not suitable for secure applications – including MultiZone.

The good news is that almost all RISC-V cores, including the tiniest 32-bit 16-register rv32e, have PMP and U mode and are therefore suitable for secure applications.

It is both! MultiZone Security is hardware-enforced, software-enabled security through separation. The necessary hardware IP blocks (“hooks”) are already built-in every standard RISC-V core that has the “U” extensions and relative Physical Memory Protection (PMP). These hardware blocks are always free of charge as  RISC-V is a free and open ISA! The software provided by Hex Five is the enabler for these hardware blocks. As the RISC-V ISA, the MultiZone Security API is also free and open. As RISC-V commercial implementations, Hex Five’s MultiZone Security commercial implementation requires a commercial license – but never ever royalties, as we hate them as much as you do!

Yes! The Multi Zone API definition is free as in “free speech” and free as in “free lunch”. It is a free and open standard open sourced under ISC permissive license for “any use”. It is maintained by Hex Five and we welcome everyone’s direct contributions in the form of a GitHub pull request. Everyone can write their own implementations of the free and open API. We are strong supporter of the commercial open source movement and  actively promote the development of a global vibrant community!

The MultiZone Security commercial implementation provided by Hex Five includes MultiZone Configurator, MultiZone nanoKernel, and MultiZone Interzone Communications. These components are distributed as part of the MultiZone Security SDK, free of charge for evaluation only. Commercial use is restricted and requires Hex Five commercial license, sometime included with the hardware itself, but never ever royalties – as we hate royalties as much as you do! Hex Five’s core components are suitable for formal verification and everyone is welcome to perform formal verification and to publish models and results. In addition, Hex Five’s source code is always available to commercial licensees for inspection and detailed code review in a clean room environment according to the term of the commercial license.

The only difference is the license. Code and functionality are the same.

The commercial license entitles Hex Five’s customers to:

• commercial use
• patent protection and indemnification
• clean room environment access to source code review
• hot line technical support
• early access to new features and security fixes
• discounted upgrade to new versions
• discounted non recurring engineering work

No, It is not.

Under the terms of the evaluation license anyone can modify zones’ code and security configuration.

https://github.com/hex-five/multizone-sdk/blob/master/LICENSE

All Hex Five Intellectual Propriety is protected domestically and internationally: patent pending US 16/450,826 PCT US19/38774 [62/689,205 62/796,967 62/796,991 62/801,091].

Except for the MultiZone core, all Hex Five source code is published on GitHub at https://github.com/hex-five

The toolchain extension mutizone.jar is not open source.

The ouput generated is 100% compliant with the free and open standard multi zone API.

Anyone can build their own implementation or license Hex Five’s commercial implementation.

Hex Five’s commercial licensees – as in paying customers – are entitled to clean room review of all Hex Five’s source code under the terms of the commercial license.

100% standard Intel Hex format – see https://en.wikipedia.org/wiki/Intel_HEX

We offer the MultiZone Development License: it is a low-cost annual subscription intended to reduce customer’s development time, cost and risk.

The MultiZone Development License includes 20 hours of technical support for:

• hot line direct access to MultiZone development team to address any technical questions on supported platforms
• non recurring engineering work to adapt core product functionality to new platforms and boards

The pro-rata cost of the Development License can be credited towards the purchase of the first commercial license once ready to move in production.

Contact us at https://hex-five.com/contact/ if you’d like to learn more.

The free and open standard multi zone API is a proposal for adoption. As of July 2022 it has not been ratified by the RISC-V Foundation.

The RISC-V multi zone API definition is free as in “free speech” and free as in “free lunch”. The API definition is a free and open standard completely open sourced under ISC permissive license for “any use”. It is maintained by Hex Five and we welcome everyone’s direct contributions in the form of a GitHub pull request. Everyone can write their own implementations of the free and open API. We are strong supporter of the commercial open source movement and  actively promote the development of a global vibrant community!

The MultiZone™ Security implementation provided by Hex Five includes MultiZone™ Configurator, MultiZone™ nanoKernel, and MultiZone™ Interzone Communications. These components are distributed as part of the MultiZone™ Security SDK, free of charge for evaluation only. Commercial use is restricted and requires Hex Five commercial license, sometime included with the hardware itself, but never ever royalties – as we hate royalties as much as you do! Hex Five’s core components are suitable for formal verification and everyone is welcome to perform formal verification and to publish models and results. In addition, Hex Five’s source code is always available to commercial licensees for inspection and detailed code review in a clean room environment.

As for the technology requirements, MultiZone™ Security is certified to work with any standard RISC-V core that has:

• RV32I, RV32E, RV64I architecture (32-bit and 64-bit) compliant with RISC-V Unprivileged ISA 2.1
• ‘U’ extension (User mode) compliant with RISC-V Privileged Architecture 1.11
• At least 4 PMP registers (recommended: 8 for single-core,  16 for multi-core)

In the very same way you debug any other RISC-V applications!

There is nothing secret, hidden, or special about MultiZone software, so no proprietary tools are required. MultiZone Security is 100% compliant with the RISC-V ISA. We believe in open source and use free and open tools for our internal development: GNU toolchain, GDB, openOCD, Eclipse CDT IDE or plain old school command line tools. But you can certainly use any other tools of choice as long as they work with RISC-V.

To get you started, take a look at the MultiZone user manual, which include detailed examples covering the full development cycle.

Nope! It’s not Ok. This is a known problem of  older versions of Linux openOCD drivers. There is a super-simple workaround: just reset the FPGA board or restart the openOCD session on your computer – if you do it, make sure you actually kill any running openocd and gdb process. Even better, try to update your Linux distribution.

Then everything works as expected: the reference application firmware takes approx 10 seconds to upload.

Don’t feel bad! MultiZone Security is such a revolutionary concept that it usually takes more than a minute or two to grasp. It is based on the state-of-the-art philosophy of zero-trust computing and security through separation – like Docker at the chip level.

Here is how it works from a development flow perspective:

• break your current monolithic design in a few separate functional blocks – i.e OS with user apps, connectivity stack, root of trust, crypto libraries, bare metal drivers for DMA, I/O, etc
• define messages and listeners for inter-zone communications as a secure and modern way to expose and consume microservices
• code, compile, debug and test each individual component separately using programming language, toolchain and development environment of choice
• write plain text MultiZone Security policies with your text editor of choice, perhaps following the examples and the comprehensive documentation provided with the MultiZone SDK
• run the MultiZone Configurator, which generates a single signed firmware image including your original binaries, the MultiZone nanoKernel, the MultiZone Messaging system and the security policies
• Flash, run and debug as usual. And perhaps use the dummy terminal app provided with the SDK to verify and test  security policies and system separation.
• Be the hero of the day. You just made the world a better – and safer – place!

What are the APIs?

The MultiZone API is optional and provided as a linkable C library wrapper, but you could use plain inline assembly if you prefer. These are exception-based helper functions to interact with the MultiZone runtime – a bit like Linux system calls. As with system calls, you need them just for very specif things such as sending and receiving messages, to speed up the emulation of privileged instructions, to register traps and interrupt handlers and to set soft-timers.

How you don’t have to rewrite software?

Good application software usually doesn’t interact directly with the hardware layer. So your apps are likely to work just fine without any modifications. System level software, such as FreeRTOS, is designed to work at the highest level of privilege and requires some minor changes to run in a secure unprivileged mode. However, MultiZone Security includes transparent support for trap & emulation of privileged instructions, so even this kind of code will run without major changes. In any case, Hex Five has already done the work for you and published a complete set of unprivileged, thus secure, versions of these software components. All open source and freely available on GitHub.

What’s the performance hit?

CPU throughput overhead is negligible. Typical context switch is in the order of 100 instructions and, depending on the implementation, it can take anything in between 120 to 180 cycles – you run the math but that’s basically nothing. Interrupt latency on the other hand may take a few extra instructions if the Zone mapped to the interrupt is not in scope.  A good use of the ECALL_YIELD() API can greatly minimize this effect. And if interrupt latency is really a requirement, there are ways to design the system separation so that the Zone associated with high priority interrupts is almost always in scope or ready to wake up from the Waiting For Interrupt state (WFI).

Where’s the proof that “no changes required”?

See the Secure IoT Stack reference application freely available on GitHub and judge yourself.

Show me some standard software running on this.

Is FreeRTOS, wolfSSL, picoTCP, and C bare metal code “standard” enough for you? If so look at the Secure IoT Stack reference application freely available on GitHub. Otherwise let us know what you consider “standard software” and we’ll gladly add a new reference example to the many already available.

Physical Memory Protection (PMP) is a RISC-V standard feature generally associated with the “U” extension. PMP has nothing to do with hardcore (silicon) vs. softcore (fpga). PMP is either implemented or not –  there is no concept of “simulating” PMP. According to SiFive’s documentation, the E310 is an RV32IMAC: no “U” means no PMP. All cores supported by MultiZone have “U” extensions and PMP including SiFive’s E24, E31, E51, S51, U540 and Hex Five’s free and open X300 – see https://github.com/hex-five/multizone-fpga

• We recommend having the board directly connected to your computer for this experience – best to avoid any intermediate switches or routers. Note that old computers you may need a crossover cable.
• Double check that the connection to the board has the IP address on the same subnet (by default the board is set to 192.168.0.2/24).
• Double check that traffic is actually flowing to the board – the lights on the Ethernet connector on the board should blink when trying to ping it. If the lights are not blinking, you need to check the route to the board and whether you have the correct IP address configured (by default the board is set to respond to 192.168.0.2).

On Linux, you can check what the system believes is the route to the board:

$ ip route get 192.168.0.2
192.168.0.2 dev enp8s0u1u4 src 192.168.0.1 uid 1000

Double check that the reported route is correct. One way is to check which connection changes state when plugging/unplugging the Ethernet cable on the board or computer side). Use the following command:

$ ip addr
9: enp8s0u1u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0f:c9:10:f5:f4 brd ff:ff:ff:ff:ff:ff

Unplug the Ethernet cable from the board or the computer and double check that the status changes:

$ ip a
9: enp8s0u1u4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:0f:c9:10:f5:f4 brd ff:ff:ff:ff:ff:ff

Finally make sure that that connection has the IP address on the same subnet as the board (by default the board is set to 192.168.0.2/24):

$ ip a
9: enp8s0u1u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0f:c9:10:f5:f4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute enp8s0u1u4
...

It should as long as QEMU provides emulation for the underlying hardware.

The MultiZone Secure IoT stack works out-of-the-box with the free and open X300 fpga shell (rv32imac) tailored for the Digilent ARTY 7 board. This small fpga board is inexpensive ($129), readily available online, compatible with the Arduino shield, and reprogrammable for different softcores https://store.digilentinc.com/arty-a7-artix-7-fpga-development-board-for-makers-and-hobbyists/

MultiZone Security for Linux provides hardware-enforced software-defined multi-domain trusted execution environment to run trusted workloads on untrusted OS (SMP Linux or AMP Linux + FreeRTOS / Zephyr / Etc).

No.

Running the trusted execution environment in the same untrusted OS core is possible but not secure:

1. the highest level of privilege (M) would be shared with the Linux SBI – definitely not a good idea security wise
2. it would not be possible to lock down the cache for exclusive use of the trusted core, therefore exposing the system to trivial side channel attacks

No. Linux kernel runs in S-mode as it requires privileged access to the MMU.

MultiZone runs on the E51 although it could run on any other core as they are identical except for the FP unit.

This is done via the MultiZone secure boot loader configuration.

Yes. Unless restricted by the policies defined in the multizone.cfg configuration file – see https://github.com/hex-five/multizone-linux/blob/master/bsp/U540/multizone.cfg. Note that policies are defined per core to support mixed-critically systems that run SMP Linux in parallel to AMP deterministic OSs like FreeRTOS, Zephyr, and similar.

Yes. All peripherals are threated equally and accessible as long as they are mapped to the core via the multizone.cfg policy file.

The UART on the Unleashed board is assigned to Linux for monitoring the boot.

The UART on the optional Microsemi expansion board is mapped to MultiZone enclave #3.

All peripherals assignments can be freely reconfigured via the multizone.cfg policy file.

Yes, it’s available and Yes, it’s a kernel module. The binary is included in Hex Five’s pre-built Linux distribution available for free download at https://hex-five.com/wp-content/uploads/multizone-linux-20190808.tar.xz.

As of September 2019, the source code is currently available only to customers and members of the MultiZone Pilot Program. It will be published on GitHub in December 2019, when the product is officially released.

Up to you. You can use the free driver developed by Hex Five or write your own implementation. The MultiZone IPC protocol is a free and open standard licensed for for any use: see specifications at https://hex-five.com/wp-content/uploads/2019/09/multizone-ipc-protocol-20190810.pdf

Yes!

To run MultiZone for Linux you need:

• MultiZone For Linux SDK https://github.com/hex-five/multizone-linux
• MultiZone secure boot loader mSD image https://hex-five.com/wp-content/uploads/multizone-linux-20190808.tar.xz

These are both available for download  at https://hex-five.com/multizone-enclave-linux. You could then replace the MultiZone BBL binary with your modified version and either use the MultiZone Linux driver to securely connect to MultiZone enclaves or write your own implementation – MultiZone IPC protocol is free and open standard licensed for “any use”.

Yes: MultiZone can enforce separation of multiple binaries in the same core. One of these binaries can be a full blown operating systems including Linux. In fact MultiZone can run multiple instances of different versions of Linux in the same core.

However, Hex Five does NOT recommend this configuration as it not secure. Linux boot and runtime require shared M-mode privileges for SBI calls and interrupts management. In addition, caches represent an unacceptable side-channel attack trivial to exploit.

That’s why Hex Five has developed MultiZone Security for Linux: the first Linux enclave for RISC-V. It secures the deterministic behavior of mixed-criticality systems where Linux and Real-Time come together in a single chip (SoC). For safety-critical applications that require trusted workloads on untrusted platforms, MultiZone™ Security provides software-defined hardware-enforced separation for multiple enclaves, with full isolation of data, programs and peripherals. Contrarily to legacy thick hypervisor solutions, MultiZone is completely self-contained, presents an extremely limited attack surface (<2KB), it’s formally verifiable, and doesn’t require changes to existing software. With MultiZone Security for Linux open source software, third party binaries and legacy code can be configured in minutes to achieve unprecedented levels of safety and security.

MultiZone memory protection is fail-secure: if something goes wrong, access is denied (rather than allowed)

All exceptions, synchronous and asynchronous, are handled in the context of the zone that triggers the fault and are guaranteed to have no effect on the other zones. This is consistent with MultiZone design philosophy of “Zero Trust”.

.

No. The MultiZone separation kernel does not log any activity as it is completely sealed from the rest of the system to minimize the attack surface.

Logging is certainly possible if implemented in user mode at the zone level: one could develop a zone whose only purpose is to receive memory protection fault messages from the kernel and store for later analysis. The response can be completely configurable and could include alerting other part of the system – and perhaps elegantly exposed as a Linux rpc service.

No. Faults don’t automatically trigger zone reset unless the zone itself is coded to do that, which seems like a reasonable implementation choice.

The SDK command line utility “RESTART” provided by zone 1 shows how to restart a zone by executing (jumping to) its very first instruction in the .text section. This is done by the zone itself in its own context. Preemptive reset/restart external to the zone context would otherwise result in an attack vector for trivial denial of service.

Updating the zones binaries has no interactions at all with MultiZone policies and MultiZone configurator. Out of the box, MultiZone does not provide or enforce any secure update mechanism for the zones binaries. Its job is to establish and maintain separation policies regardless of the code that runs in each enclave.

No. In fact the MultiZone configurator does not compile any code as it receives in input fully linked binaries.

As far as MultiZone is concerned zones binaries can change at any time. On the other hand, policies can only be changed statically via the MultiZone configurator and require a system reset.