microsoft/cheriot-safe

Repo for CHERI development system

Project

Cheriot-safe (CHERIoT small and fast FPGA emulator) is an complete FPGA platform for CHERIoT hardware prototyping and embedded software development. It contains a cheriot-ibex core, CHERIoT-enabled risc-v debug modules, TCM memories, an AXI-based internal bus fabric, and a collection of commonly used peripherals.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

Setting up Access

In a browser go to: https://github.com/microsoft/cheriot-safe
Click on the purple squigily item in the upper right corner. 
Select Settings
Select SSH and GPG keys
Add your SSH key
Authenticate key.

Checking out the Repo

git clone [email protected]:microsoft/cheriot-safe.git  <ws>
cd <ws>
git submodule update --init --recursive

Running a verilator simulation

See the readme and examples under sim/verilator.

Running a VCS simulation

1. Review the ./sim/Makefile for the correct path to the vcs simulator.
2. Execute: ./trun hello_world
3. Test output is in ./out/run/hello_world/...

Building FPGA bitfile

See the readme under build/

Board Support

Currently cheriot-safe supports the Diligent Arty A7-100T board.

Design documentation

See the wiki section for more information about the cheri_safe FPGA design

cheriot-safe's Issues

Building cheriot-safe for Artix-A7 100T

Hello,

I have been attempting to build the core for the Arty-A7 100T. I did get it to build but I wanted to point something out and also would like some guidance for getting CHERIot compiled software running on the core.

Software

I am using Vivado 2022.2

Commit used

31ddb47

Steps I used to build

1. I created a new project in Vivado targeting the Arty-A7 100T
2. For source directories I added: All directories in
   a. All directories from src excluding msft_cheri_tb
   b. rtl/ from cheriot-ibex folder
   c. vendor/lowrisc_ip from cheriot-ibex
3. The top file for me was automatically detected which is: msftDvIp_cheri_arty7_fpga.sv
4. I added the constraint file from this reo

During synthesis and implementatin

When I was synthesising using the Vivado (running as a GUI), I encountered this error:

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.

      < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sck0_i_IBUF] >
      sck0_i_IBUF_inst (IBUF.O) is locked to IOB_X1Y114
       and sck0_i_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31

So I added this line to the constraint file in the repo:

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sck0_i_IBUF]

After adding the line, I managed to build and generate the bitstream.

My questions

1. I when I uploaded the bitstream, LED4 was blinking and it is labeled alive_o, is this a watchdog LED and does it indicate the system is working correctly?
2. I did compile the LLVM project (cheriot branch) for the compiler. Which produced the clangd binary. How do I go about running software on this core (on the Arty-A7 100T).
3. Was the constraint file change fine to use?

Thanks!

Arty A7 35T support

I was following the instructions in issue: #3

Neither the hello world nor the charity sanity check are producing any UART output for me while using the Arty A7 with the 35T. Is this because I do not have the 100T or are we expecting these instructions to work for the 35T as well?

Building fails due to extra connection

I tried to build the core following the instructions in the build directory, but it failed with the following error:

INFO: [Synth 8-6155] done synthesizing module 'ibex_top' (0#1) [/home/xxxxx/temp/cheriot-safe/cheriot-ibex/rtl/ibexc_top.sv:20]
INFO: [Synth 8-6155] done synthesizing module 'ibex_top_tracing' (0#1) [/home/xxxxx/temp/cheriot-safe/cheriot-ibex/rtl/ibexc_top_tracing.sv:13]
ERROR: [Synth 8-349] instance 'ibex_top_i' of module 'ibex_top_tracing' passed 49 connections, but takes just 48 [/home/xxxxx/temp/cheriot-safe/src/msft_cheri_core/msftDvIp_cheri_core_wrapper.sv:105]

To reproduce:

cd build
./build_arty_a7

It looks like the extra connection is cheri_fatal_err_o, which I can't find in the ibex_top_tracing module

I used vivado v2023.1 (64-bit) for linux.
I'm not sure if I've got a file out of date

CHERIoT SAFE 33MHz fails to catch some spatial memory safety violations

It seems that CHERIoT SAFE on the Arty A7 fails to catch some spatial safety violations.

Here is a proof of concept:

diff --git a/examples/01.hello_world/hello.cc b/examples/01.hello_world/hello.cc
index 17ec80c..d3a72ae 100644
--- a/examples/01.hello_world/hello.cc
+++ b/examples/01.hello_world/hello.cc
@@ -11,6 +11,18 @@ using Debug = ConditionalDebug<true, "Hello world compartment">;
 /// Thread entry point.
 void __cheri_compartment("hello") say_hello()
 {
-       // Print hello world, along with the compartment's name to the default UART.
-       Debug::log("Hello world");
+   Debug::log("Corrupting the allocator.");
+   struct Timeout    timeout = {0, UnlimitedTimeout};
+   volatile uint8_t *x1 =
+     (uint8_t *)heap_allocate(&timeout, MALLOC_CAPABILITY, 0x20);
+   Debug::log("Got capability {}", x1);
+   Debug::log("Capability after addition {}", (volatile void **)(x1 + 0x20));
+   *(volatile void **)(x1 + 0x20) = (void *)-1;
+   Debug::log("Done. Now running the allocator to get an assert.");
+   for (int i = 0; i < 10; i++)
+   {
+       auto p = heap_allocate(&timeout, MALLOC_CAPABILITY, 10);
+       heap_free(MALLOC_CAPABILITY, p);
+   }
+   Debug::log("Exiting.");
 }
diff --git a/examples/01.hello_world/xmake.lua b/examples/01.hello_world/xmake.lua
index 3483e64..69e8898 100644
--- a/examples/01.hello_world/xmake.lua
+++ b/examples/01.hello_world/xmake.lua
@@ -27,8 +27,8 @@ firmware("hello_world")
                 compartment = "hello",
                 priority = 1,
                 entry_point = "say_hello",
-                stack_size = 0x200,
-                trusted_stack_frames = 1
+                stack_size = 0x1000,
+                trusted_stack_frames = 2
             }
         }, {expand = false})
     end)

Just patch this into the CHERIoT RTOS repo (https://github.com/microsoft/cheriot-rtos), and build 01.hello_world for 33MHz with debugging enabled for the memory allocator. Running it on the Arty A7, you should see the following:

Ready to load firmware, hold BTN0 to ignore UART input.                              
                                                                                     
Ready to load firmware, hold BTN0 to ignore UART input.                              
Starting loading.  First word was: 40812A15                                          
.................................................                                    
Finished loading.  Last word was: 020001F4                                           
Number of words loaded to IRAM: 000030AC                                             
Loaded firmware, jumping to IRAM.                                                    
                                                                                     
Hello world compartment: Corrupting the allocator.                                   
Hello world compartment: Got capability 0x20049510 (v:1 0x20049510-0x20049530 l:0x20 o:0x0 p:
 G RWcgm- -- ---)                                                                    
Hello world compartment: Capability after addition 0x20049530 (v:1 0x20049510-0x20049530 l:0x
20 o:0x0 p: G RWcgm- -- ---)                                                         
Hello world compartment: Done. Now running the allocator to get an assert.           
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest          
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk                                                                   
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
../../sdk/core/allocator/alloc.h:2253 Assertion failure in tmalloc_smallest
Free chunk 0x20049538 (v:1 0x20049400-0x20080000 l:0x36c00 o:0x0 p: G RWcgm- -- ---) follows 
another free chunk
Hello world compartment: Exiting.
Error handler: BoundsViolation(0x1) error at 0x2004862e (v:0 0x20048360-0x20048f80 l:0xc20 o:
0x0 p: G R-cgm- X- ---) (return address: 0x0 (v:0 0x0-0x0 l:0x0 o:0x0 p: - ------ -- ---)), w
ith capability register CRA(0x1): 0x0 (v:0 0x0-0x0 l:0x0 o:0x0 p: - ------ -- ---)

The overflow is not detected and it corrupts the allocator which gets some assertion violations (!).

I seem to be able to get similar behavior on the stack:

diff --git a/examples/01.hello_world/hello.cc b/examples/01.hello_world/hello.cc
index 17ec80c..e7e40b5 100644
--- a/examples/01.hello_world/hello.cc
+++ b/examples/01.hello_world/hello.cc
@@ -11,6 +11,28 @@ using Debug = ConditionalDebug<true, "Hello world compartment">;
 /// Thread entry point.
 void __cheri_compartment("hello") say_hello()
 {
-	// Print hello world, along with the compartment's name to the default UART.
-	Debug::log("Hello world");
+	Debug::log("Corrupting a stack value.");
+	uint8_t a[12] = {0};
+	CHERI::Capability<uint8_t> cap{a};
+	cap.bounds() = 2;
+	volatile uint8_t *b = cap;
+	Debug::log("a {}; b {}", a, b);
+	Debug::log("a[2] before corruption: {}", a[2]);
+	* (volatile void **)(b + 0x1) = (void*) -1;
+	Debug::log("a[2] after corruption: {}", a[2]);
+
+	Debug::log("Corrupting the allocator.");
+	struct Timeout    timeout = {0, UnlimitedTimeout};
+	volatile uint8_t *x1 =
+	  (uint8_t *)heap_allocate(&timeout, MALLOC_CAPABILITY, 0x20);
+	Debug::log("Got capability {}", x1);
+	Debug::log("Capability after addition {}", (volatile void **)(x1 + 0x20));
+	*(volatile void **)(x1 + 0x20) = (void *)-1;
+	Debug::log("Done. Now running the allocator to get an assert.");
+	for (int i = 0; i < 10; i++)
+	{
+		auto p = heap_allocate(&timeout, MALLOC_CAPABILITY, 10);
+		heap_free(MALLOC_CAPABILITY, p);
+	}
+	Debug::log("Exiting.");
 }
diff --git a/examples/01.hello_world/xmake.lua b/examples/01.hello_world/xmake.lua
index 3483e64..69e8898 100644
--- a/examples/01.hello_world/xmake.lua
+++ b/examples/01.hello_world/xmake.lua
@@ -27,8 +27,8 @@ firmware("hello_world")
                 compartment = "hello",
                 priority = 1,
                 entry_point = "say_hello",
-                stack_size = 0x200,
-                trusted_stack_frames = 1
+                stack_size = 0x1000,
+                trusted_stack_frames = 2
             }
         }, {expand = false})
     end)

Here it simply hangs, without triggering a fault, which seems to be an indicator that the stack is corrupted.

Additional information

• This does not reproduce on the emulator (on any emulator in fact, neither the IBEX SAFE emulator nor SAIL. There you will simply see the faults, as expected.
• @davidchisnall reproduced this bug on another A7 board, so this is likely not due to a faulty board.
• @davidchisnall also found out that this only happens on the 33MHz and not on the 20MHz, so something went wrong when changing the clock speed.
• This was found while investigating this bug which went unnoticed for a long time because the memory safety violation wasn't caught.

Action required: migrate or opt-out of migration to GitHub inside Microsoft

Migrate non-Open Source or non-External Collaboration repositories to GitHub inside Microsoft

In order to protect and secure Microsoft, private or internal repositories in GitHub for Open Source which are not related to open source projects or require collaboration with 3rd parties (customer, partners, etc.) must be migrated to GitHub inside Microsoft a.k.a GitHub Enterprise Cloud with Enterprise Managed User (GHEC EMU).

Action

✍️ Please RSVP to opt-in or opt-out of the migration to GitHub inside Microsoft.

❗Only users with admin permission in the repository are allowed to respond. Failure to provide a response will result to your repository getting automatically archived.🔒

Instructions

Reply with a comment on this issue containing one of the following optin or optout command options below.

✅ Opt-in to migrate

@gimsvc optin --date <target_migration_date in mm-dd-yyyy format>

Example: @gimsvc optin --date 03-15-2023

OR

❌ Opt-out of migration

@gimsvc optout --reason <staging|collaboration|delete|other>

Example: @gimsvc optout --reason staging

Options:

• staging : This repository will ship as Open Source or go public
• collaboration : Used for external or 3rd party collaboration with customers, partners, suppliers, etc.
• delete : This repository will be deleted because it is no longer needed.
• other : Other reasons not specified

Need more help? 🖐️

• Email [email protected]. ✉️
• Post your questions in GitHub inside Microsoft Team in Microsoft Teams. 🗨️