To provide guaranteed streaming delivery in https://github.com/hex-five/multizone-secure-iot-stack, we needed to create mzmsg, examples https://github.com/hex-five/multizone-secure-iot-stack/blob/master/zone1/mzmsg.c and https://github.com/hex-five/multizone-secure-iot-stack/blob/master/zone2/main.c#L171.

mzmsg adds complexity and performance overhead and will need to be reinvented for every case. It would be simpler to provide send and recv methods that return success/failure. This could be used to offer queue sematics. E.g.

• for send

int ret;
ret = ECALL_TRYSEND(4, (int[4]){1,2,3,4});
// ret is SUCCESS
ret = ECALL_TRYSEND(4, (int[4]){5,6,7,8});
// ret is FAIL, would overwrite message

• for recv

int msg[4];
int ret;
ret = ECALL_TRYRECV(4, msg);
// ret is SUCCESS, msg can be anything, even all zeros
ret = ECALL_TRYRECV(4, msg);
// ret is FAIL, no messages available

Having these available makes the whole concept of mzmsg redundant and eliminates the need for decoupling queues, saving RAM in the zones.

I would like the multizone tool to check my individual zone's linker script to confirm whether the memory or sections are actually allowed in the multizone configuration.

Suggested interaction (the -l flag specifies the linker script for the last passed zone):

$ java -jar multizone.jar zone1/zone1.hex -l zone1/flash.lds zone2/zone2.hex -l zone2/flash.lds zone3/zone3.hex -l zone3/flash.lds --arch=$(BOARD)

ERROR: zone1/flash.lds maps the following section which is not allowed in zone's configuration:
  ram   (wxa!ri) : ORIGIN = 0x80001000, LENGTH =  16K
Closest match is
  base = 0x80001000; size =    4K; rwx = rw # RAM

Could you please give further details about how the secure boot process of the MultiZone works?

In the paper "Multi Zone Security for Arm Cortex-M Devices", it is explained like that:
""
TEE Secure Boot Process. The TEE implements a 2-stage secure boot loader to verify the integrity and authenticity of the firmware image (SHA-256) and to minimize runtime memory footprint and target attack surface.
""
What are these 2 stages and what contains this signed firmware image (only zones?)?

Because in case of HiFive1 Rev B board (Reference Application):
The Multizone Kernel (Runtime) is flashed to 0x20010000 and bootloader is flashed to the 0x20012000 (see picture below).
Does it mean that the kernel will be executed and then call the bootloader (boot section the picture below) which will check the integrity and authenticity of the zones? Or is the boot section the signature of the zones?

I would be really happy, if you can explain me the further details of how the secure boot flow really works?

There is no documentation or indication of where are the docs, making it difficult to compile and deploy.

Can multizone be used to protect docker containers? If so, how to achieve it

I need the following stuff checked in the nanokernel for the X300:

mvendorid      0x57c	1404
marchid        0x1	1
mimpid         0x20181004	538447876

Add additional boards to Makefile

Zone three is missing two pieces of functionality that make it usable without the robot:
Z1 > send 3 r | g | b - should cause the flashing LED to change color
Z1 > send 1 ping should result in Z3 > pong response

I have already burn X300 softcore on to Arty-35T and refence https://static.dev.sifive.com/SiFive-E310-arty-gettingstarted-v1.0.6.pdf connect Arty-35T,host machine and ARM-USB-TINY-H, but when i try to run make load,an error occureed, it said:

/home/a/riscv-openocd-20200613/bin/openocd -f bsp/X300/openocd.cfg &
/home/a/riscv-gnu-toolchain-20200613/bin/riscv64-unknown-elf-gdb multizone.hex --batch -ex "set mem inaccessible-by-default off" -ex "set remotetimeout 240" -ex "set arch riscv:rv32" -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit"
Open On-Chip Debugger 0.10.0+dev-00860-g97fb3f4bd (2020-06-13-20:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
The target architecture is assumed to be riscv:rv32
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
openocd: src/target/riscv/riscv-011.c:431: dbus_scan: Assertion info->addrbits != 0' failed. localhost:3333:connect time out. "monitor" command not supported by this target. "monitor" command not supported by this target. You can't do that when your target is exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

Is that means i connect wrong wires?
Thank you.

Hey :)

is it possible to prevent the interruption of a security-critical routine for a short amount of time,
maybe somehow configurable in the MultiZone config?
From my understanding, any Zone can use its own multiplexed instance of the timer interrupt and this can't be
prevented. Therefore, in theory a malicious zone could use this timer interrupt to interrupt another zone on purpose, is it not?

I know this situation is extremely specific and that it is unlikely, that such behavior can be used on purpose.
But for the Remote Attestation procedure mentioned in #53 atomicity of the attestation routine is a requirement
and despite very unlikely, there may be security concerns if targeted interruption of the Attestation procedure and shared memory access are combined.

Thanks in advance,
Anton

when "make load " is executed there is an error called
riscv-gnu-toolchain-20210618/bin/riscv64-unknown-elf-gdb: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by riscv-gnu-toolchain-20210618/bin/riscv64-unknown-elf-gdb)
I am currently using virtualBox to emulate ubuntu 20 on my windows desktop.
Any help is appreciated. Thank you

To continue we started with the official website https://github.com/hex-five/multizone-sdk on our virtual box with ubuntu machine and we are trying to connect "Arty A7 100T" board. Now we are working on the arty a7 board and now we are curious to explore more on the boards that could help us in Achieving our goal. Can you let me know on the details of other boards that we could try to work on.

I am student from Texas A&M university as my professor wanted to research on RISCV with multizone. To continue we started with the official website https://github.com/hex-five/multizone-sdk on our virtual box with ubuntu machine and we are trying to connect "Arty A7 100T" board. Now we want to find out if the board is still supported by the company and if not, what board should we purchase to be fully supported. So that we could reach our goal.

Reported on: 7edf433

The handle_syncexception function always increments the mepc by 4, this will skip over a compressed instruction which is 2 bytes long and can cause unintended consequences:

Observed so far is when a Load address misaligned fault triggers (#18):

Z1 > stats
1152873 cycles in 17737 us 
 148681 cycles in  2287 us 
1053322 cycles in 16205 us 
1050395 cycles in 16160 us 
1090923 cycles in 16783 us 
 630100 cycles in  9694 us 
1161786 cycles in 17874 us 
 538041 cycles in  8277 us 
 625049 cycles in  9616 us 
Load address misaligned : 0x00000004 0x204102ca 0x2041490c 
Load address misaligned : 0x00000004 0x204102c6 0x20414910 
Illegal instruction : 0x00000002 0x0000fcf4 0x20414914 

Hello, I am trying to load the reference application on HiFive1 Rev B on Ubuntu 22.04.3 LTS. I did all of the steps written in the manual, section installation, and could successfully build the reference application, and got the following output:

===================================================================
HEX-Five MultiZone Security
Patents US 11,151,262 and PCT/US2019/03877
Copyright 2020 Hex Five Security, Inc. - All Rights Reserved

This version of MultiZone Security is meant for evaluation purposes
only. As such, use of this software is governed by the Evaluation
License. There may be other functional limitations as described in
the evaluation SDK documentation. The commercial version of the
software does not have these restrictions.

Kernel : section 0 address 0x40400000 size 0x00001a1c 7 KB
Boot : section 0 address 0x40402000 size 0x00000018 1 KB
Zone 1 : section 0 address 0x40408000 size 0x00003be4 15 KB
Zone 2 : section 0 address 0x40406000 size 0x00000926 3 KB
Zone 3 : section 0 address 0x40404000 size 0x00000b88 3 KB
Zone 4 : section 0 address 0x40403000 size 0x0000047c 2 KB
Warning: zone 3 region 3 overlaps zone 2 region 4.

However, once I tried to load the application on board (by running make load), I got the following error message:

Open On-Chip Debugger 0.11.0+dev-01860-g9aa8bab63-dirty (2021-08-08-01:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
Error: no device found
Error: unable to open ftdi device with vid 15ba, pid 002a, description 'Olimex OpenOCD JTAG ARM-USB-TINY-H', serial '' at bus location ''

The target architecture is set to "riscv:rv32".
localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

I would be really happy if you could help me with the issue.

Best regards

Details

Reported on: ba86fd3
Bitstream: E31 v3p0

Steps to reproduce

1. Compile and load multizone-sdk
2. Connect UART
3. Turn on robotic arm

Expected results

Z3 > USB DEVICE ATTACH VID=0x1267 PID=0x0000

Actual results

Z3 > USB DEVICE ATTACH VID=0x1267 PID=0x0000
Z2 > ???

hex-five/multizone-secure-iot-stack uses files from this repo inside the ext/multizone folder. It would be easier to track changes and use subtree or submodule concepts if the folders were similar - to that end, it would make sense to extract the files from the libhexfive folder into the root of the repo - hex-five/multizone-sdk.

Hey there,

on your website you mention that the MultiZone runtime is formally verifiable and written in Assembly. Is the code of this runtime publicly available anywhere? I wasn't able to find any further information on that.

Thanks in advance,
Anton

Hey :)

for my bachelors thesis, I am designing a Remote Attestation procedure on top of MultiZone.
My design uses a dedicated attestation zone to read and hash the memory of application zones.

Clearly, this use-case doesn't work with the MultiZone secure communication interface and in the paper
(Secure IoT Firmware For RISC-V Processors, 2021) you state that no shared memory is used for communication. As I understand it, this primarily regards the communication interface provided by MultiZone, but is it actually discouraged to use shared memory?

The reference application uses it for GPIO and the MultiZone Configurator emits a warning, but I wasn't sure
if this approach is future-proof or whether mapping a memory region to multiple zones may be prohibited eventually.

Thanks in advance,
Anton

I'm attempting to run this Zephyr sample as a zone on the HiFive1 Rev B (FE310). I compile the sample with Zephyr's given SDK and then move it into its own directory inside of the MultiZone SDK. I run these commands to produce the hex (then fix the address as it points to 0x20010000) and lst files:

toolchain-path/bin/riscv64-unknown-elf-objcopy -O ihex zephyr.elf zephyr-old.hex --gap-fill 0x00

toolchain-path/bin/riscv64-unknown-elf-objdump --all-headers --demangle --disassemble --file-headers --wide -D zephyr.elf > zephyr.lst

/root/workspace/multizone-riscv/riscv-gcc-toolchain/bin/riscv64-unknown-elf-objcopy --change-addresses 0x2800 zephyr-old.hex zephyr.hex

I've updated the Makefile to appropriately use this new zone as such:

$(MAKE) -C bsp/$(BOARD)/boot java -jar multizone.jar \ --arch $(BOARD) \ --config bsp/$(BOARD)/multizone.cfg \ --boot bsp/$(BOARD)/boot/boot.hex \ zephyr/zephyr.hex

To receive this output after compiling:

make -C bsp/FE310/boot clean
make[1]: Entering directory '/root/workspace/multizone-riscv/multizone-sdk/bsp/FE310/boot'
rm -f boot.o boot.hex boot.elf boot.lst boot.map
make[1]: Leaving directory '/root/workspace/multizone-riscv/multizone-sdk/bsp/FE310/boot'
rm -f multizone.hex
make -C bsp/FE310/boot
make[1]: Entering directory '/root/workspace/multizone-riscv/multizone-sdk/bsp/FE310/boot'
/root/workspace/multizone-riscv/riscv-gcc-toolchain/bin/riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 -ffreestanding -Wall -x assembler-with-cpp -c -o boot.o boot.S
/root/workspace/multizone-riscv/riscv-gcc-toolchain/bin/riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 -ffreestanding -Wall -T linker.lds -T ../memory.lds -nostdlib -Xlinker --gc-sections -Wl,-Map,boot.map -o boot.elf ./boot.o
/root/workspace/multizone-riscv/riscv-gcc-toolchain/bin/riscv64-unknown-elf-objcopy -O ihex -j.boot boot.elf boot.hex
/root/workspace/multizone-riscv/riscv-gcc-toolchain/bin/riscv64-unknown-elf-objdump --source --all-headers --demangle --disassemble --line-numbers --reloc --wide boot.elf > boot.lst
make[1]: Leaving directory '/root/workspace/multizone-riscv/multizone-sdk/bsp/FE310/boot'
java -jar multizone.jar
--arch FE310
--config bsp/FE310/multizone.cfg
--boot bsp/FE310/boot/boot.hex
zephyr/zephyr.hex
====================================================================
MultiZone Security Configurator
Copyright 2020 Hex Five Security, Inc. - All Rights Reserved
====================================================================
This version of MultiZone Security is meant for evaluation purposes
only. As such, use of this software is governed by the Evaluation
License. There may be other functional limitations as described in
the evaluation SDK documentation. The commercial version of the
software does not have these restrictions.
====================================================================
Kernel : section 0 address 0x20010000 size 0x0000170c
Boot : section 0 address 0x20012000 size 0x0000003c
Zone 1 : section 0 address 0x20012800 size 0x00003f68
Warning: zone 3 range 3 overlaps zone 2 range 4.
17:57:08 Build Finished (took 857ms)

After running a make load to have the SEGGER J-Link flash the HiFive1 Rev B, I connect to the board via screen and receive no output after resetting the board.

MultiZone and Zephyr do work right out of the box in their respective directories, but I'm failing to get them to pair.

Hello,

I try to redo the demonstration of Multizone secure Iot Stack but arrived at the step to upload the .hex file to the Arty 100T card and the debbuger JTAG ARM-USB-TINY-H, I have the following error :

home/aldwin/Documents/M2_CSSE/Project_HexFive/hexfive/softwares/riscv-openocd-20200613/bin/openocd -f bsp/X300/openocd.cfg &
/home/aldwin/Documents/M2_CSSE/Project_HexFive/hexfive/softwares/riscv-gnu-toolchain-20200613/bin/riscv64-unknown-elf-gdb multizone.hex --batch -ex "set mem inaccessible-by-default off" -ex "set remotetimeout 240" -ex "set arch riscv:rv32" -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit"
Open On-Chip Debugger 0.10.0+dev-00860-g97fb3f4bd (2020-06-13-20:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Unsupported DTM version: 15
The target architecture is assumed to be riscv:rv32
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Unsupported DTM version: 15
Error: Unsupported DTM version: 15
Remote communication error. Target disconnected.: Connexion ré-initialisée par le correspondant.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

I've already checked the wires several times.

Is it properly plugged in?
Is there another cause for this problem?
Thank you.

Description

InterZone seems to overwrite the posted message before it was received under certain circumstances.

Reported on: ba86fd3
Bitstream: E31 v3p0

Steps to reproduce

1. Clone or apply warpBytes@d711d17
2. Connect UART
3. Compile and upload

Expected results

Sent message to zone 2

Actual results

Sent message to zone 2
Sent message to zone 2

Reported on: 0e5d4a8
Reproduced on boards: S51

Description

Sending messages to zone3 to change the color has no effect.

Steps to reproduce

Z1 > send 3 red

Z1 > send 3 gree

Z1 > send 3 blue

There are no instructions about how to obtain the compiler or openocd binaries. After a while, I could generate all binaries from the own repository. The instructions to do that from a fresh ubuntu 18.04 install are:

1 - Install all system dependency packets:

sudo apt install build-essential git gawk texinfo bison flex libgmp-dev libmpfr-dev libmpc-dev libexpat1-dev libtool automake libusb-1.0-0-dev minicom

2 - From the directory /multizone-sdk/riscv-gnu-toolchain generate the compiler:

./configure --enable-multilib --prefix=
make

3 - From the directory multizone-sdk/riscv-openocd generate the openocd:

./bootstrap
./configure --enable-ftdi --prefix=/home/crmoratelli/hexfive/riscv-openocd
make
make install

4 - Export the following variables:

export RISCV=
export OPENOCD=

5 - You are ready to compile and load the multizone-sdk:

make
make load

The documentation specifies the message format as 4 ints, are these 32-bit ints or 64-bit ints on a 64-bit system? it would perhaps be better to specify in terms of bytes or 4xn-bit integers.

The FreeRTOS zone will lock up after a board reset. Indicators are LD0 not blinking, LD1 stops changing and the Telnet CLI doesn't work (Telnet connection and ping still work, though). The lock-up is observed with multizone.jar from Embedded-World-2019 (9075b73) and master (f31aaa2). Lock-up does not occur with the latest multizone.jar from oneoff-sandro-irq branch (0a11fd1).

AS A developer using Eclipse,
I WANT an Ecplise plugin to edit the multizone.cfg file,
SO THAT I don't have to manually edit and can benefit from automated checks.

Add documentation for using reference toolchain and openocd as submodules have been removed from this repo.

Hello,

According to README, MultiZone SDK supports also the SiFive Unleashed U540 board. Could someone write down the necessary steps (or modifications to the existing repo) to build MultiZone SDK in U540 board? I am aware of the multizone-linux repo for U540 but I would really like to build this SDK as well. Thanks!

The fence declaration was removed from Zone 1 - can you clarify syntax and support.

Is there any reason not to include it in this demo?

Reported on: 0e5d4a8
Reproduced on boards: E31, S51 (somewhat)

Description

Running yield repeatedly on E31 will give the time 300-400us. Running the stats command will give the time aroud 19us. On the S51 the yield variance is bigger, sometimes matching the stats output in a couple of numbers.

Steps to reproduce

Z1 > yield
yield : elapsed time 297us

Z1 > yield
yield : elapsed time 297us

Z1 > yield
yield : elapsed time 297us

Z1 > yield
yield : elapsed time 297us

Z1 > yield
yield : elapsed time 436us

Z1 > yield
yield : elapsed time 303us

Z1 > yield
yield : elapsed time 436us

Z1 > yield
yield : elapsed time 436us

Z1 > stats
1252 cycles in 19 us
1581 cycles in 24 us
1242 cycles in 19 us
1576 cycles in 24 us
1242 cycles in 19 us
1579 cycles in 24 us
1243 cycles in 19 us
1577 cycles in 24 us
1242 cycles in 19 us
1578 cycles in 24 us
1242 cycles in 19 us
------------------------------------------------
cycles  min/med/max = 1242/1252/1581
time    min/med/max = 19/19/24 us

ctx sw instr  min/med/max = 120/120/120
ctx sw cycles min/med/max = 205/208/209
ctx sw time   min/med/max = 3/3/3 us

multizone could generate the linker scripts based on a template to support multiple boards. All the information is already available in the multizone configuration.

For the following multizone.cfg:

Zone = 1 # 
	base = 0x40410000; size =   64K; rwx = rx # FLASH
        base = 0x80001000; size =    4K; rwx = rw # RAM

and the template zone1/flash.lds.template:

/* Copyright(C) 2018 Hex Five Security, Inc. - All Rights Reserved */

OUTPUT_ARCH( "riscv" )

ENTRY( _start )

MEMORY {
  $FLASH
  $RAM
}

...

running the tool would generate the following zone1/flash.lds:

/* Copyright(C) 2018 Hex Five Security, Inc. - All Rights Reserved */
/* This file is generated from zone1/flash.lds.template. Local modifications will be lost. */

OUTPUT_ARCH( "riscv" )

ENTRY( _start )

MEMORY {
  flash (rxai!w) : ORIGIN = 0x40410000, LENGTH = 64K
  ram   (wxa!ri) : ORIGIN = 0x80001000, LENGTH =  4K
}

...

PLIC interrupt for sources > 31 are always routed to zone1 despite being mapped to other zones.
This is likely to result in a denial of service for both zone1 and the zone mapped to the plic source > 31.

We used to have PLIC interrupt functionality, last commit where it was working was 7b94f9c. We didn't implement this functionality in commit a7606a7, believing CLIC should be enough. With 20/20 hindsight, it's good to demonstrate PLIC interrupts, too.

I am trying to integrate AI and multizone can someone help me out in giving any references on how small entry level programs of AI models can be executed in multizone platforms.

I am having some issues with OpenOCD that are causing the make load for my Arty 35T to fail. Most likely related to my local setup, but quite difficult to debug.

However, loading the pre-build .msc file to the board with Vivado works. I was wondering if there are any resources on how to build this file, so that I can use it as an alternative for building an loading the SoC + firmware without using OpenOCD.

On rv32 the higher part of the return value is undetermined - i.e. getting 0x1_0000057c as a return from ECALL_CSRR_MVENDIND() instead of just 0x0000057c in certain cases.

Affected APIs:

uint64_t ECALL_CSRR_MISA();
uint64_t ECALL_CSRR_MVENDID();
uint64_t ECALL_CSRR_MARCHID();
uint64_t ECALL_CSRR_MIMPID();
uint64_t ECALL_CSRR_MHARTID();

Reported on: 7edf433

Steps to reproduce

1. Connect via telnet and run stats in zone1

% telnet 192.168.1.2
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.

FreeRTOS CLI

Z1 > stats
1152873 cycles in 17737 us 
 148681 cycles in  2287 us 
1053322 cycles in 16205 us 
1050395 cycles in 16160 us 
1090923 cycles in 16783 us 
 630100 cycles in  9694 us 
1161786 cycles in 17874 us 
 538041 cycles in  8277 us 
 625049 cycles in  9616 us 
Load address misaligned : 0x00000004 0x204102ca 0x2041490c 
Load address misaligned : 0x00000004 0x204102c6 0x20414910 
Illegal instruction : 0x00000002 0x0000fcf4 0x20414914 

Press any key to restart

2. Connect via UART to zone4 and exchange running stats and pmp commands while stats in zone1 is still running (need to possibly repeat many times to trigger, here I did each at least 4-5 times):

...
Z4 > pmp
0x20440000 0x2044ffff r-x 
0x8000a000 0x8000afff rw- 
0x10013000 0x100130ff rw- 
0x10012000 0x100120ff rw- 

Z4 > stats
 83425 cycles in 1283 us 
692631 cycles in 10656 us 
701294 cycles in 10789 us 
706411 cycles in 10868 us 
 93280 cycles in 1435 us 
703660 cycles in 10825 us 
706237 cycles in 10865 us 
705069 cycles in 10847 us 
133379 cycles in 2052 us 
700962 cycles in 10784 us 
688880 cycles in 10598 us 
------------------------------------------------
cycles  min/med/max = 83425/700962/706411 
time    min/med/max = 1283/10784/10868 us 

ctx sw instr  min/med/max = 123/123/123 
ctx sw cycles min/med/max = 236/236/236 
ctx sw time   min/med/max = 3/3/3 us 

Z4 > pmp
0x20440000 0x2044ffff r-x 
0x8000a000 0x8000afff rw- 
0x10013000 0x100130ff rw- 
0x10012000 0x100120ff rw- 

Z4 >

hi,
i am very new to linux security.I am using sifive's u540 hifive unleashed and want to test working of multizone on the same.But i am unable to do so ,steps i am following is
1)i have downloaded the pre-built toolchain from
http://hex-five.com/download

2)tar -xvf riscv-gnu-toolchain-20181226.tar.xz
tar -xvf riscv-openocd-20181226.tar.xz
git clone https://github.com/hex-five/multizone-sdk
sudo apt-get install libusb-0.1-4
sudo apt-get install screen

3)sudo vi /etc/udev/rules.d/99-openocd.rules

These are for the HiFive1 Board

SUBSYSTEM=="usb", ATTR{idVendor}=="0403",
ATTR{idProduct}=="6010", MODE="664", GROUP="plugdev"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403",
ATTRS{idProduct}=="6010", MODE="664", GROUP="plugdev"

These are for the Olimex Debugger for use with E310 Arty Dev Kit

SUBSYSTEM=="usb", ATTR{idVendor}=="15ba",
ATTR{idProduct}=="002a", MODE="664", GROUP="plugdev"
SUBSYSTEM=="tty", ATTRS{idVendor}=="15ba",
ATTRS{idProduct}=="002a", MODE="664", GROUP="plugdev"

4. export RISCV=/home/embd/riscv-gnu-toolchain-20181226
   export OPENOCD=/home/embd/riscv-openocd-20181226
   export PATH="$PATH:/home/embd/riscv-gnu-toolchain-20181226/bin"

5. cd multizone-sdk/
   make clean
   make BOARD=u540
   ake BOARD=U540
   Makefile:34: *** recipe commences before first target. Stop.

How use this for U540 can you help ??

Reported on: 0e5d4a8
Reproduced on boards: E31, S51

Description

Pinging zone1 doesn't produce a pong on neither E31 nor S51, pinging zone3 doesn't produce a pong on S51. Moreover, pinging zone1 repeatedly will give "Error: Inbox full" on both.

Steps to reproduce

1. Load bitstream
2. Issue the following commands and observe the results

   Z1 > send 1 ping
   
   Z1 > send 2 ping
   
   Z2 > pong
   
   Z1 > send 3 ping
   
   Z1 > send 1 ping
   Error: Inbox full.
   

Tried to check on the Multizone-sdk github link and worked on it and found this as my problem for now to solve I would need your help please help me out on doing this.

/home/ramyab/riscv-openocd-20210807/bin/openocd -f bsp/X300/openocd.cfg &
/home/ramyab/riscv-gnu-toolchain-20210618/bin/riscv64-unknown-elf-gdb multizone.hex --batch -ex "set mem inaccessible-by-default off" -ex "set remotetimeout 240" -ex "set arch riscv:rv32" -ex "target extended-remote localhost:3333" -ex "monitor reset init" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit"
Open On-Chip Debugger 0.11.0+dev-01860-g9aa8bab63-dirty (2021-08-08-01:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
The target architecture is set to "riscv:rv32".
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Warn : target riscv.cpu examination failed
Info : starting gdb server for riscv.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
openocd: src/target/riscv/riscv-011.c:435: dbus_scan: Assertion info->addrbits != 0' failed. localhost:3333: Connection timed out. "monitor" command not supported by this target. "monitor" command not supported by this target. You can't do that when your target is exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

The connection of JTAG is done by referring to the documentation provided by sifive and jtag producers (Olimex) But still we are getting this error . Any help is Appreciated. Thank you

Zone 1 splash screen still has revision 0.1.1; should be updated to 1.0 per release version.

Details

Reported on: ba86fd3
Bitstream: E31 v3p0

Steps to reproduce

1. Compile and upload multizone-sdk
2. Connect UART
3. send 1 p
4. send 2 p
5. send 3 p

Expected results

Z1 > send 1 p

Z1 > pong

Z1 > send 2 p

Z2 > pong

Z1 > send 3 p

Z3 > pong

Actual results

Z1 > send 1 p

Z1 > send 2 p

Z1 > send 3 p

Reported against: 7edf433

I experience a semi-random behavior when trying to restart zone1 over telnet. Zone2 remains functional as I can ping it still. LD0 and LD1 stop doing anything and stats show times < 10ms which indicates no tasks running in zone1.

Here are steps how to reproduce:

➜  ~ telnet 192.168.1.2
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.

FreeRTOS CLI

Z1 > restart

FreeRTOS CLI

Z1 > restart

FreeRTOS CLI

Z1 > restart

FreeRTOS CLI

Z1 > restart

FreeRTOS CLI

Z1 > restart

FreeRTOS CLI

Z1 > restart

I noticed the oneoff-sandro-irq branch (commit 8c58edb) has an issue related to a wrong PMP configuration (nanokernel context-switch) on a zone's interrupt entry - please make sure traps are registered so that it can be noticed.

---------- How to replicate:

/* Add trap 0x1 handler - Instruction Address Fault */

void trap_0x1_handler(void)attribute((interrupt("user")));
void trap_0x1_handler(void){
...
}

/* Register trap on main */
int main (void){
...
ECALL_TRP_VECT(0x1, trap_0x1_handler); // 0x1 Instruction access fault
...
}

@borancar Check SiFive's latest documentation and freedom-e-sdk PLIC driver to see what may have changed.