Learn by doing

clone our soc

set it up using the instructions here

find bugs

find out more about the bugs


Get our HACK@DAC 2019 SoC

If you use our SoC in your academic work you can cite us:

@inproceedings {236236,
author = {Ghada Dessouky and David Gens and Patrick Haney and Garrett Persyn and Arun Kanuparthi and Hareesh Khattri and Jason M. Fung and Ahmad-Reza Sadeghi and Jeyavijayan Rajendran},
title = {HardFails: Insights into Software-Exploitable Hardware Bugs},
booktitle = {28th {USENIX} Security Symposium ({USENIX} Security 19)},
year = {2019},
isbn = {978-1-939133-06-9},
address = {Santa Clara, CA},
pages = {213–230},
url = {https://www.usenix.org/conference/usenixsecurity19/presentation/dessouky},
publisher = {{USENIX} Association},
month = aug,

Alpha Stage SoC Simulation Setup 

SoC simulation setup is done in three stages. 

Stage 1: Download all the required files Stage 2: Set up the RISC-V toolchain Stage 3: Set up the Ariane SoC

● Please check the notes at the end of each section if you encounter any issue with the toolchain. 

● Run steps 5.b, 6.a, and 10.a before running a Modelsim simulation in a new terminal.

Download all the required files: 

1. To make sure that you have everything in one place, create a new directory, say 

“hackdac_alpha”. This directory will be called as the root directory through out the rest of this document 

a. Mkdir hackdac_alpha 

2. Download the files “toolchain_source.zip” and “ariane.zip” from the google drive link 

below into the root directory https://drive.google.com/drive/folders/1PV2cxkkORiqjE04r5EIVL0a8EszlZc_M?usp=sharing


Setting up the toolchain : 

3. Unzip the toolchain source folder in the root directory, this should create a folder called 


a. unzip toolchain_source.zip 

4. Install dependencies for building the toolchain 

a. For Ubuntu-based systems: 

sudo apt-get install autoconf automake autotools-dev curl 

libmpc-dev libmpfr-dev libgmp-dev libusb-1.0-0-dev gawk 

build-essential bison flex texinfo gperf libtool 

patchutils bc zlib1g-dev device-tree-compiler pkg-config 


b. For Fedora-based systems: 

sudo dnf install autoconf automake @development-tools curl 

dtc libmpc-devel mpfr-devel gmp-devel libusb-devel gawk 

gcc-c++ bison flex texinfo gperf libtool patchutils bc 

zlib-devel expat-devel 

5. Create a directory to install the toolchain in the root directory and setup a variable named 

“RISCV” that points to the location 

a. mkdir riscv-tools 

b. export RISCV=<path_to_root_directory/riscv-tools> 

c. cd toolchain_source 

d. ./build.sh 

e. cd ../ 

6. Add the riscv tool binaries to the path list. 

a. export PATH=$RISCV/bin:$PATH 

7. To generate .elf files, create the C source code you want to run in the “software” 

sub-directory in the “toolchain_source” directory. Update and run the the Makefile present there accordingly. For example, to generate the .elf for hello_world.c: 

a. cd software b. mkdir hello_world c. echo ‘int main(int argc, char** argv) {printf(“Hello World\n”); return 0; } ‘ > hello_world/hello_world.c d. sed -i ‘s/dhrystone/dhrystone hello_world /g’ Makefile e. make all 

This will generate the “hello_world.riscv” elf file. 

Notes : 

● This should install the RISCV toolchain in your system. 

● If step 5 gives you errors, try to install all the dependencies listed in step 4. 

● If you do not have sudo access to install the dependencies, then the toolchain has to be installed on some other system where you have sudo access. (For example, in a virtual machine). 

● If you are installing the toolchain on one system (e.g., Ubuntu) with sudo access and want to run the SoC simulation in another system (e.g., CENTOS) without sudo access, then do the following (otherwise ignore these steps) : 

● Install the RISCV toolchain on the Ubuntu system following the above steps 1 to 7. You will then use this to generate your elf files. 

● Create the root directory “hackdac_alpha” in CENTOS as well, and copy the “riscv-tools” directory from LINUX system to the CENTOS system’s root directory 

● Do the steps 5.b and 6.a in the CENTOS. 

● Download the “fesvr_source.zip” file from the google drive previously mentioned in the document. 

● Install the fesvr tool : 

a. unzip fesvr_source.zip b. cd riscv-fesvr c. mkdir build d. cd build e. ../configure –prefix=$RISCV –target=riscv64-unknown-elf f. make install g. cd ../../ 

● The toolchain does not work this way in your CENTOS system, but we can still manage to run the SoC. 

Create a dummy “software” directory in the root directory of your CENTOS system and copy the elf files generated in the LINUX system to this directory


Setting up the Ariane SoC : 

8. Unzip the SoC in the root directory, this should create a directory named “ariane” 

a. unzip ariane.zip 

9. In ariane/Makefile file, after line 75, you might have to include the Modelsim library file path with the appropriate path for your system (it will be < modelsim tool installation >/includes directory) with a “-I” prefix. Depending on your system, it might work without including this path. See the commented line 76 for reference. 

10. Source the Modelsim/Questasim license file. See example below. 

a. source 


11. Export RISCV and add riscv-tools binaries to the path list. 

a. export RISCV=<path_to_root_directory/riscv-tools> 

b. export PATH=$RISCV/bin:$PATH 

12. Copy the elf file generated from the step 6 into the ariane directory. (You can also use 

the “hello.elf” file that is present in the “ariane” directory or “ariane/elf_files” directory) 

a. cp -r ../software/<elf_name>.riscv . 

13. Run the simulation 

a. make sim elf-bin=<elf_name>.riscv 

Please check the list of bugs inserted

Bug List

The following bugs were inserted into the SoC:




Processor access to CLINT grants it access to PLIC regardless of PLIC access configuration


Peripherals can be disabled by the user


UART cannot be accessed even from Machine mode


DMA can write to inaccessible regions if privilege level changed during the DMA read


Incorrect access control setting leaving debug enabled


Access control registers can be accessed behind the register locks


DMA can be used to access unprivileged registers


PLIC registers are not protected by access control


Execute machine level instructions from user mode


AES key stored in an unprotected register


AES internal registers are visible externally


Constant initial vector used for AES


Counter register in AES CTR mode does not increase


Crypto oracle for encrypt/decrypt is exposed to unprivileged applications


AES key is hard coded


SHA is not properly checked during Boot test


Bootrom can be corrupted by user mode applications


Address range overlap between a protected register file and an unprotected peripheral


CPU halts when writing to undefined address location


Access to CSRs from lower privilege level


Receive CSR interrupts when committing atomic instructions


Commit the second instruction even if the first is atomic instruction


Pipeline not flushed after committing an atomic instruction


SATP register (read) accessible in Supervisor mode even if TVM is enabled


SATP register (write) accessible in Supervisor mode even if TVM is enabled


Pipeline not flushed after change in virtual address translation mode


RTC is using wrong clock input


Same cycle counter used for both CSR mcycle and cycle


Instruction retired counters are updated in non-debug mode


IRQ source input badly connected


SoC uses asynchronous resets


Exception signal is not set at halt


Fan speed can be controlled from unprivileged application


Timing register can be accessed from lower privilege level


Multiple signal drivers in interrupt handling


System functions can be overwritten by underprivileged applications


Assignment to an incorrect literal value leads to incorrect memory size


Traps due to usage fault and system calls have same priority in trap handler


Data from previous DMA transfer can be copied by giving undefined read address location


DMA will cause huge amount of bus traffic if start and clear bits are set at the same time


DRAM memory region is fully accessible from lower privilege level


The implementation of strcmp system call is not constant in time


Protected memory regions can be accessed through system call address pointer arguments


AES key stored in memory at bootup and is not cleared before exiting from firmware setup


Secure registers are accessible via AXI


Jtag reference password port is not driven


Some JTAG instructions can be accessed without password


Unlocking JTAG sets the processor privilege level to Machine mode


JTAG password is only 32 bits


Authorized debugs can access FUSE memory


JTAG password flag not reset properly


JTAG reset uninitialized


Debug module does not reset on a system reset


JTAG key is hardcoded


JTAG not temporarily disabled after several continuous wrong password attempts


Secondary Reset Control through Debug exposed to SW


JTAG password input can be a high impedance state


Register locks can be reprogrammed after boot-up


Register locks can be reset by triggering software reset through JTAG


DMA registers are not locked


UART registers are not locked


Reg locks are disabled by default when reset


Incorrect register lock settings for Access control registers


SHA input data not cleared after HASH computation


Intermediate values of SHA are leaked


The SHA wrapper uses non-blocking assignment for variables which can cause timing issues

For more info about bugs