HACK@DAC
2019

Learn by doing

clone our soc

set it up using the instructions here

find bugs

find out more about the bugs

enjoy

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 

“toolchain_source” 

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 

libexpat-dev 

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 

/opt/coe/mentorgraphics/modelsim/setup.modelsim.bash 

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:

#

Bug

1

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

2

Peripherals can be disabled by the user

3

UART cannot be accessed even from Machine mode

4

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

5

Incorrect access control setting leaving debug enabled

6

Access control registers can be accessed behind the register locks

7

DMA can be used to access unprivileged registers

8

PLIC registers are not protected by access control

9

Execute machine level instructions from user mode

10

AES key stored in an unprotected register

11

AES internal registers are visible externally

12

Constant initial vector used for AES

13

Counter register in AES CTR mode does not increase

14

Crypto oracle for encrypt/decrypt is exposed to unprivileged applications

15

AES key is hard coded

16

SHA is not properly checked during Boot test

17

Bootrom can be corrupted by user mode applications

18

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

19

CPU halts when writing to undefined address location

20

Access to CSRs from lower privilege level

21

Receive CSR interrupts when committing atomic instructions

22

Commit the second instruction even if the first is atomic instruction

23

Pipeline not flushed after committing an atomic instruction

24

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

25

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

26

Pipeline not flushed after change in virtual address translation mode

27

RTC is using wrong clock input

28

Same cycle counter used for both CSR mcycle and cycle

29

Instruction retired counters are updated in non-debug mode

30

IRQ source input badly connected

31

SoC uses asynchronous resets

32

Exception signal is not set at halt

33

Fan speed can be controlled from unprivileged application

34

Timing register can be accessed from lower privilege level

35

Multiple signal drivers in interrupt handling

36

System functions can be overwritten by underprivileged applications

37

Assignment to an incorrect literal value leads to incorrect memory size

38

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

39

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

40

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

41

DRAM memory region is fully accessible from lower privilege level

42

The implementation of strcmp system call is not constant in time

43

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

44

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

45

Secure registers are accessible via AXI

46

Jtag reference password port is not driven

47

Some JTAG instructions can be accessed without password

48

Unlocking JTAG sets the processor privilege level to Machine mode

49

JTAG password is only 32 bits

50

Authorized debugs can access FUSE memory

51

JTAG password flag not reset properly

52

JTAG reset uninitialized

53

Debug module does not reset on a system reset

54

JTAG key is hardcoded

55

JTAG not temporarily disabled after several continuous wrong password attempts

56

Secondary Reset Control through Debug exposed to SW

57

JTAG password input can be a high impedance state

58

Register locks can be reprogrammed after boot-up

59

Register locks can be reset by triggering software reset through JTAG

60

DMA registers are not locked

61

UART registers are not locked

62

Reg locks are disabled by default when reset

63

Incorrect register lock settings for Access control registers

64

SHA input data not cleared after HASH computation

65

Intermediate values of SHA are leaked

66

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

For more info about bugs