Where do I start?
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
What are MultiZone hardware requirements?
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)
How do I know if a generic RISC-V processor has "U" extensions?
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.
Is MultiZone Security hardware or software?
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!
Is MultiZone Security free?
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.
What's the difference between the free MultiZone version on GitHub and the commercial one?
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
Is MultiZone configuration hardcoded?
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
Is multizone.jar the item HexFive protects in the free version?
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
Is the MultiZone toolchain extension multizone.jar open and do we get the sources as well?
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.
What exact HEX format is the MultiZone toolchain extension multizone.jar outputting?
What kind of support do you provide to help prospects develop their Proof Of Concept?
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.
Is Multi-Zone Trusted Execution Environment truly formal RISC-V spec or in other words based completely on formal RISC-V spec awaiting RISC-V Foundation approval, without being enriched by any company-specific added code ['secret juice'] at all?
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)
How do I debug MultiZone based applications?
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.
Flashing the Secure IoT Stack firmware takes forever, is that Ok?
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.
I've been writing systems software for 30 years, and I couldn't understand what this actually does, what the APIs are, and how you don't have to rewrite software. What's the performance hit? Where's the proof that "no changes required"? Show me some standard software running on this.
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.
Do chips like Sifive E310 (FPGA) offer physical memory protection or are those chips simulated and only used for testing/development? Is there a list of chips that support it on hardware vs simulated somewhere?
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
I can't connect to the MultiZone Secure IoT Stack via Ethernet, what do I do?
- 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 ...
MultiZone Secure IoT Stack: Does it run on the QEMU included with FreedomStudio?
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/
What is the security concept behind MultiZone Linux Enclave?
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).
MultiZone Linux Enclave: Does it run MultiZone in M, MultiZone zones in U, Linux in S, and Linux user space processes in U?
No.
Running the trusted execution environment in the same untrusted OS core is possible but not secure:
- the highest level of privilege (M) would be shared with the Linux SBI – definitely not a good idea security wise
- 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
MultiZone Linux Enclave: Does Linux run in U mode?
No. Linux kernel runs in S-mode as it requires privileged access to the MMU.
MultiZone Linux Enclave: On what core does MultiZone run?
MultiZone runs on the E51 although it could run on any other core as they are identical except for the FP unit.
MultiZone Linux Enclave: What is the mechanism whereby MultiZone enclaves and Linux are assigned to specific cores?
This is done via the MultiZone secure boot loader configuration.
MultiZone Linux Enclave: Does Linux have access to all the peripherals?
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.
MultiZone Linux Enclave: The diagram mentions Ethernet but would that extend to the UART etc.?
Yes. All peripherals are threated equally and accessible as long as they are mapped to the core via the multizone.cfg policy file.
MultiZone Linux Enclave: How is the UART peripheral handled?
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.
MultiZone Linux Enclave: Is the MultiZone IPC driver available? Is it a kernel module?
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.
MultiZone Linux Enclave: Do we need the MultiZone driver for our own Linux distro to communicate with enclaves via MultiZone IPC?
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
MultiZone Linux Enclave: Does it run with my own modified Linux distro?
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”.
Can MultiZone run Linux inside a zone?
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.
Is MultiZone memory protection fail-secure, fail-safe or configurable?
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”.
.
Is there any sort of logging/tracing for failed memory access?
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.
Can memory protection faults trigger zone reset?
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.
How can an enclave APP have a secured updated?
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.
Is one required to compile all the APPs bin with the multizone configurator to genereate a single combined FW image?
No. In fact the MultiZone configurator does not compile any code as it receives in input fully linked binaries.
Is there any option to change enclave programs at run time?
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.