skip to Main Content

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 complex MultiZone Secure IoT Stack

If you are an Ada developer, look at MultiZone Security For Ada.

What are MultiZone hardware requirements?

MultiZone Security works with any RISC-V core that has:

  • RV32I, RV32E, RV64I architecture (32-bit and 64-bit))
  • ‘U’ extension (User mode)
  • 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 of 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 MultiZone Security 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 API 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.

 

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. There is a bug in the X300 bitstream and we’re working hard to fix it. In the meanwhile, 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.

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
...

 

Back To Top