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 |