Matthew Cole’s Homepage

Accepted Paper at IEEE S&P ‘23

2022-11-10T01:24:00+00:00

Our paper Control Flow and Pointer Integrity Enforcement in a Secure Tagged Architecture by Ravi Theja Gollapudi, Gokturk Yuksek, David Demicco, Matthew Cole, Gaurav Kothari Rohit Kulkarni, Xin Zhang, Kanad Ghose, Aravind Prakash and Zerksis Umrigar has been accepted at 44th IEEE Symposium on Security and Privacy (IEEE S&P 2023). I’m particularly proud of this work, as it’s the culmination of over five years of work under the DARPA System Security Integration Through Hardware and Firmware (SSITH) Program to provide secure architectures for systems that are essential to modern life.

@INPROCEEDINGS{10179416,
  author={Gollapudi, Ravi Theja and Yuksek, Gokturk and Demicco, David and Cole, Matthew and Kothari, Gaurav and Kulkarni, Rohit and Zhang, Xin and Ghose, Kanad and Prakash, Aravind and Umrigar, Zerksis},
  booktitle={2023 IEEE Symposium on Security and Privacy (SP)}, 
  title={Control Flow and Pointer Integrity Enforcement in a Secure Tagged Architecture}, 
  year={2023},
  volume={},
  number={},
  pages={2974-2989},
  abstract={Control flow attacks exploit software vulnerabilities to divert the flow of control into unintended paths to ultimately execute attack code. This paper explores the use of instruction and data tagging as a general means of thwarting such control flow attacks, including attacks that rely on violating pointer integrity. Using specific types of narrow-width data tags along with narrow-width instruction tags embedded within the binary facilitates the security policies required to protect against such attacks, leading to a practically viable solution. Co-locating instruction tags close to their corresponding instructions within cache lines eliminates the need for separate mechanisms for instruction tag accesses. Information gleaned from the analysis phase of a compiler is augmented and used to generate the instruction and data tags. A full-stack implementation that consists of a modified LLVM compiler, modified Linux OS support for tags and a FPGA-implemented CPU hardware prototype for enforcing CFI, data pointer and code pointer integrity is demonstrated. With a modest hardware enhancement, the execution time of benchmark applications on the prototype system is shown to be limited to low, single-digit percentages of a baseline system without tagging.},
  keywords={},
  doi={10.1109/SP46215.2023.10179416},
  ISSN={2375-1207},
  month={May},}

Accepted Paper at WDFHC ‘22

2022-11-01T11:59:00+00:00

Our paper A Security Analysis of Labeling-Based Control-Flow Integrity Schemes by David Demicco, Matthew Cole, Shengdun Wang and Aravind Prakash has been accepted at Workshop on Data Fabric for Hybrid Cloud 2022 (WDFHC ‘22).

@INPROCEEDINGS{10056531,
  author={Demicco, David and Cole, Matthew and Wang, Shengdun and Prakash, Aravind},
  booktitle={2022 IEEE 29th International Conference on High Performance Computing, Data and Analytics Workshop (HiPCW)}, 
  title={A Security Analysis of Labeling-Based Control-Flow Integrity Schemes}, 
  year={2022},
  volume={},
  number={},
  pages={47-52},
  abstract={Secure and transparent policy enforcement by a cloud provider is crucial in cloud infrastructures. Particularly, enforcement of control-flow integrity (CFI) policy has been widely accepted for stopping software-induced attacks. Using low-level hardware metadata to encode CFI policy is a fairly recent development. Besides moving enforcement out of the software and into the hardware for performance benefit, tagging metadata also offers other benefits in the precision of defenses. We evaluate several different metadata layouts for CFI policy enforcement, and examine the layouts' effects on the number of valid forward edges remaining in a RISC-V binary after policy enforcement. Additionally we look at related work in tag-based tools that provide CFI policy enforcement in order to get a sense of their performance and the design trade-offs they make. We evaluate our policy and the related works in terms of space and precision trade-offs for forward- and backward-edge CFI, finding that some trade-offs have a higher impact on the number of remaining forward edges, notably return address protection. Additionally, we report that existing backward edge protections can be highly effective, reducing the number of remaining backward edges in a protected binary to an average of 0.034% over an equivalent coarse-grained CFI.},
  keywords={},
  doi={10.1109/HiPCW57629.2022.00011},
  ISSN={},
  month={Dec},}

Accepted Paper at NordSec ‘22

2022-10-06T17:42:00+00:00

Our paper Simplex: Repurposing Intel Memory Protection Extensions for Secure Storage by Matthew Cole and Aravind Prakash has been accepted at Nordic Conference on Secure IT Systems (NordSec ‘22). The acceptance rate was 22.5%.

@InProceedings{10.1007/978-3-031-22295-5_12,
author="Cole, Matthew
and Prakash, Aravind",
editor="Reiser, Hans P.
and Kyas, Marcel",
title="Simplex: Repurposing Intel Memory Protection Extensions for Secure Storage",
booktitle="Secure IT Systems",
year="2022",
publisher="Springer International Publishing",
address="Cham",
pages="215--233",
abstract="The last few decades have seen several hardware-level features to enhance security, but due to security, performance, and/or usability issues these features have attracted steady criticism. One such feature is the Intel Memory Protection Extensions (MPX), an instruction set architecture extension promising spatial memory safety at a lower performance cost due to hardware-accelerated bounds checking. However, recent investigations into MPX have found that is neither as performant, accurate, nor precise as software-based spatial memory safety. Given its ubiquity, we argue that it provides an under-utilized hardware resource that can be salvaged for security purposes. We propose Simplex, an open-sourced library that re-purposes MPX registers as general purpose registers. Using Simplex, we demonstrate securely storing sensitive information directly on the hardware (e.g. encryption keys). We evaluate for performance, and find that deployment is feasible in all but the most performance-intensive code, with amortized performance overhead as low as about 1{\%}.",
isbn="978-3-031-22295-5"
}

Building LLVM for RISC-V Cross Compilation

2018-11-26T20:26:00+00:00

So you want to build software for the RISC-V architecture (I’m playing with the Open ISA Vega RV32M1 development board)? Great, you’ll need a compiler. Although GCC officially supports you, with full upstream support as of GCC 7.1 and binutils 2.28, if you’re interested in hacking the compiler before building software, you’ve probably chosen LLVM. In that case, you’ll need a bit more effort to get LLVM to build as a cross-compiler.

Prerequisites

This process assumes that you begin in the directory where your RISC-V GNU build tools and LLVM project directories will reside. You will need to determine the following locations, and expand them into a fully qualified path (i.e. /home/user/... not ~/...) wherever they appear in a command.

Location	Description	Example Value
`$TOP`	The location where you want your cross-compiler	`export TOP=$(pwd)`
`$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT`	The location where the GNU toolchain installs itself.	`/$TOP/riscv-gnu-toolchain/install`
`$LLVM_INSTALL_ROOT`	The location where LLVM installs itself.	`/$TOP/llvm-project/install`

You’ll also need some packages. This tutorial presumes Ubuntu 18.04.2 LTS, and thus gets the packages from Aptitude. These instructions will probably also work for other operating systems as well, you’re just on your own for package management.

sudo apt-get update
sudo apt-get install autoconf automake autotools-dev bison build-essential \
  cmake curl flex gawk gcc gcc-multilib gperf libmpc-dev libmpfr-dev \
  libgmp-dev libncurses5-dev make ninja-build openjdk-8-jre python python3 \
  texinfo u-boot-tools zlib1g-dev 

Installation

Change to the directory at which you want your cross-compiler source tree and set $TOP to this directory.

export TOP=$(pwd)

Get the RISC-V GNU Toolchain

Briefly, the RISC-V foundation maintains a RISC-V GNU toolchain for x86 cross-compilation, which you will need to cross-compile. The build tooling handles this for you, more information here.

cd $TOP
git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain
mkdir install && export RISCV_GNU_TOOLCHAIN_INSTALL_ROOT=$(pwd)/install
./configure --prefix=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT --with-arch=rv32imc --with-abi=ilp32
make -j

Get the LLVM Project Monorepo

The LLVM project monorepo is the easiest way to get all of the sources and put them in the correct location. Previously, one had to acquire all of the individual LLVM projects and extract them to the correct subdirectories in order for CMake to detect that you wanted to build these subprojects. Now, we simply specify these in the CMake invocation (see Build LLVM).

cd $TOP
git clone https://github.com/llvm/llvm-project.git

If you’d like to set your repository to a particular project release, reset the repository to the release’s commit SHA (e.g. d0d8eb2) or its tag (e.g llvmorg-7.0.1), for example:

cd $TOP/llvm-project
git reset --hard llvmorg-7.0.1`.

Build LLVM

cd $TOP/llvm-project
mkdir build install && export LLVM_INSTALL_ROOT=$(pwd)/install
cd build
cmake -G Ninja \
  -DCMAKE_BUILD_TYPE="Debug" \
  -DCMAKE_INSTALL_PREFIX="$LLVM_INSTALL_ROOT" \
  -DBUILD_SHARED_LIBS=True \
  -DLLVM_USE_SPLIT_DWARF=True \
  -DLLVM_OPTIMIZED_TABLEGEN=True \
  -DLLVM_BUILD_TESTS=True \
  -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="RISCV" \
  -DLLVM_ENABLE_PROJECTS="clang;lld;debuginfo-tests" \
  -DDEFAULT_SYSROOT="$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT/riscv32-unknown-elf" \
  -DGCC_INSTALL_PREFIX="$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT" \
  -DLLVM_DEFAULT_TARGET_TRIPLE="riscv32-unknown-elf" \
  ../
cmake --build . --target install
cmake --build . --target check-all

If you’d prefer a simple go/no-go test on the build, instead of running the time-expensive check-all target in the last step, inspect the return value (echo $?) of the first cmake --build command for a value of 0.

Invoking the Compiler

If you set the default sysroot (-DDEFAULT_SYSROOT), GCC install prefix (-DGCC_INSTALL_PREFIX) and default target triple (-DLLVM_DEFAULT_TARGET_TRIPLE) when building using CMake, you don’t need to pass these arguments explicitly when invoking Clang:

$LLVM_INSTALL_ROOT/bin/clang [options...] infile

Otherwise, you do have to pass these arguments when invoking Clang:

$LLVM_INSTALL_ROOT/bin/clang \
  --sysroot=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT/riscv32-unknown-elf \
  --gcc-toolchain=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT \
  --target=riscv32-unknown-elf \
  [options...] infile 

Since passing these arguments can be tedious, you can alias these commands:

alias riscv-clang=$LLVM_INSTALL_ROOT/bin/clang --sysroot=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT/riscv32-unknown-elf --gcc-toolchain=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT --target=riscv32-unknown-elf
alias riscv-clang++=$LLVM_INSTALL_ROOT/bin/clang++ --sysroot=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT/riscv32-unknown-elf --gcc-toolchain=$RISCV_GNU_TOOLCHAIN_INSTALL_ROOT --target=riscv32-unknown-elf
alias | grep riscv-clang

Building SPEC CPU2017 Sandboxes

2018-08-04T00:39:00+00:00

You may want to build a sandbox if one or more of these sound familiar:

You want to build recognizable, representative binaries instead of toy programs for experimentation, but you also don’t want the overhead of the actual SPEC CPU2017 benchmark suite, nor a script to manage the binaries’ execution.
You want to modify the source code of the benchmarks without corrupting the SPEC CPU2017 source tree. Modifying the source code is allowed if you use the strict_rundir_verify=no option in your configuration file, or if you create a modified installation of the benchmark using the convert_to_development utility. But an easier option is to create sandboxes for each benchmark program you wish to investigate, and it doesn’t corrupt the source tree if you’re reusing it with other experiments.
You want to modify the options or inputs provided to the benchmarks to investigate how the benchmark binaries respond.

About SPEC CPU2017

SPEC CPU2017 is a benchmark suite containing compute-intensive programs for measuring performance on a variety of computer systems. In addition to running representative programs developed from real applications with representative data sets, CPU2017 includes a driver program – runcpu – which calls necessary utilities for benchmarking.

specmake builds the benchmark binaries. If you want to try linking a library into the benchmark binaries, specmake will not permit this because only a subset of typical compiler options are available.
specinvoke invokes the binaries and times their execution. Part of this invocation is using a specified input data set. If you want to provide your own inputs, or don’t want the timing information output to the console, this is problematic.
specdiffcompares the output of the benchmark to supplied outputs for the data sets. If you have modified the binary in order to perform an evaluation other than performance, these comparisons will fail, generating unnecessary errors.

Overview

See these two pieces of official documentation (but don’t follow them at this time):

Briefly, we use runspec –action buildsetup to create a standalone build directory and build the desired binaries. Then we invoke the binaries from the command line.

Sandbox Creation and Employment

Configure the Sandbox

Copy sandbox.cfg and sandbox.sh from $SPEC/config/tiny-examples/ to $SPEC/config/ (note that by default, runspec will search $SPEC/config/ for sandbox.cfg and halts creation if it’s not found; the official instructions don’t mention this).
Modify sandbox.cfg as required. Note that this is where you’re going to specify any special specmake variables on a benchmark-by-benchmark basis.
Source sandbox.sh to generate the sandbox.
Make modifications to source file as desired. Note that it may be required to copy over input files from $SPEC/benchspec/CPU/$BENCHMARK/data/**

Build and Run the Sandbox Binaries

Be sure to source $SPEC/shrc if specmake is not in your $PATH (try which specmake to determine if this is required). If you don’t, you will receive a specmake: command not found error in step 3. Your $PWD must be $SPEC when you source shrc or else you will receive a Can’t find the top of your SPEC tree error.
Change directory to the benchmark’s build directory within the sandbox. The sandbox itself defaults to /tmp/demo_buildsetup as specified by the output_root variable in sandbox.cfg, and thus the build directories are located at /tmp/demo_buildsetup/benchspec/CPU/**/build/
Do a specmake –dry-run to verify that specmake will build the benchmark properly. Particularly observe that your specmake special variables’ ordering is sane, such that the compilation and linking commands are each well formed.
Run specmake to actually build your binary.
Execute the binary using the command line interface specified in the benchmark descriptions. You can also find examples of invocation within $SPEC/result/CPU2017.*.log files.

Example configuration and scripting

#!$SPEC/bin/runcpu
# $SPEC/config/sandbox.cfg

# Edit these variables to link a library to the sandbox
%define MYLIB_PATH /home/matthew/github/bingseclab/MYLIB
%define MYLIB_LIB_PATH %{MYLIB_PATH}/lib
%define MYLIB_INCL_PATH %{MYLIB_PATH}/incl

# Edit these variables to configure your sandbox
%define SANDBOX MYLIB
action = buildsetup
label = %{SANDBOX}-base
output_root = /tmp/sandbox_%{SANDBOX}
runlist = 519.lbm, 531.deepsjeng
tune = base
default=base:
  OPTIMIZE = -march=native -fno-unsafe-math-optimizations

# Configure benchmark builds (passed to specmake)
519.lbm_r,619.lbm_s: #lang='C'
 COBJOPT = -c -g -O0 -o $@
 EXTRA_CFLAGS = -I%{MYLIB_INCL_PATH} -L%{MYLIB_LIB_PATH}
 EXTRA_LDFLAGS = -I%{MYLIB_INCL_PATH} -L%{MYLIB_LIB_PATH}
 EXTRA_LIBS = -lMYLIB

531.deepsjeng_r,631.deepsjeng_s: #lang='CXX'
 CXX = /usr/bin/g++
 CXXOBJOPT = -c -g -O0 -o $@
 EXTRA_CXXFLAGS = -I%{MYLIB_INCL_PATH} -L%{MYLIB_LIB_PATH}
 EXTRA_LDFLAGS = -I%{MYLIB_INCL_PATH} -L%{MYLIB_LIB_PATH}
 EXTRA_LIBS = -lMYLIB

#!/bin/bash
# sandbox.sh
# see "Stupid Assumptions" in $(SPEC)/config/tiny-examples/contents

runcpu --config=sandbox | grep log
grep Makefile.spec /tmp/sandbox-MYLIB/result/CPU2017.001.log

Source Code Analysis for Design Patterns

2018-05-27T00:00:00+00:00

Design pattern extraction tools analyze source code and attempt to match the code to a collection of specimen design patterns. We reviewed tools announced by peer-reviewed literature, and found that the existing tools are unsatisfactory for use by modern C++ developers and analysts.

Summary

We explored the corpus of existing design pattern extraction tools. We found papers for 9 tools. Additionally, we found citations for three other tools within the corpus, but the links to these tools were broken.

6/9 supported C++. 1/9 claimed to be at least nominally language agnostic because its annotation/markup scheme can be applied to any text file.
2/9 claimed open source status.
6/9 were design pattern miners, that is, given source code they claim to be able to identify design patterns within the source code. The others were design pattern discoverers, that is, given annotated source code, they identify intra-class relationships that suggest that they may form a design pattern (but they cannot observe code and say “this class matches the singleton pattern” or “that method implements singleton::getInstance()”.
0/9 were all of open source, available for download, support C++, and are design pattern miners.

We’ll continue to look for design pattern miners that meet our needs. Without design pattern extraction capabilities, our solution will require manual annotation and this will not scale. We believe that design pattern discovery remains an open problem, and is profitable for reverse engineering.

Reviewed Works

Tool or Paper	Languages	Open Source?	Pattern Discovery or Mining?	Notes
DP-Miner	Java	No	Discovery	Needs a pre-constructed XMI file for project. Authors claim XMI can be generated with tools like Rational Rose.
DeMIMA	C++, Java	No	Discovery	Requires documenting components with OMT class diagrams
SPQR	?	No (patent pending)	Mining	Introduces concept of Elemental Design Patterns: 26 patterns authors found simple enough to express in logical systems. Only works on these Elemental Design Patterns.
Design Pattern Detection Using Similarity Scoring	Java	No. Authors don’t claim open-source status, and could not find source.	Mining	Uses similarity scoring on graph of class inheritance using Java byte code. Does not appear to be able to identify class method:pattern function mapping.
DPET	C++	Authors do not claim open-source status, and could not find source.	Mining	-
An efficient tool for recovering Design Patterns from C++ Code	C++	Uses proprietary software (“Understand for C++”) to generate a SQL database, which their solution then analyzes. Did not provide analysis artifact reference.	Mining	Introduces ability to infer aggregations.
Mining Design Patterns from C++ Source Code (Columbus, DPML)	C++	Authors do not claim open-source status, and could not find source.	Mining and Discovery	Introduces DPML, extending existing DP annotation schemes to mark “inheritance, composition, aggregation and association,… call delegation, object creation and operation overriding”. One of first to look at function bodies, not just class’ structure.
Evaluating C++ Design Pattern Miner Tools (Columbus/CAN)	C++	Yes.	Mining and Discovery	Extends/Improves Columbus. Announces availability through FrontEndArt. Download link is dead.
A Toolchain for Reverse Engineering C++ Applications (G4RE/G4API)	C++	Yes	Neither	Paper only claims ability to perform reverse engineering analysis that may reveal design patterns.

Dead Ends

The following were cited as possible Design Pattern mining solutions, but links are dead:

FUJABA : http://www.cs.uni-paderborn.de/cs/fujaba/
PTIDEJ: http://ptidej.iro.umontreal.ca
CPPX: http://swag.uwaterloo.ca/~cppx/download.html

Accepted Paper at ACSAC ‘17

2017-08-19T22:29:00+00:00

Our paper Supplementing Modern Software Defenses with Stack-Pointer Sanity by Anh Quach, Matthew Cole and Aravind Prakash has been accepted at ACSAC ‘17. The acceptance rate was 19.7%.

@inproceedings{10.1145/3134600.3134641,
author = {Quach, Anh and Cole, Matthew and Prakash, Aravind},
title = {Supplementing Modern Software Defenses with Stack-Pointer Sanity},
year = {2017},
isbn = {9781450353458},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/3134600.3134641},
doi = {10.1145/3134600.3134641},
abstract = {The perpetual cat-and-mouse game between attackers and software defenders has highlighted the need for strong and robust security. With performance as a key concern, most modern defenses focus on control-flow integrity (CFI), a program property that requires runtime execution of a program to adhere to a statically determined control-flow graph (CFG). Despite its success in preventing traditional return-oriented programming (ROP), CFI is known to be ineffective against modern attacks that adhere to a statically recovered CFG (e.g., COOP).This paper introduces stack-pointer integrity (SPI) as a means to supplement CFI and other modern defense techniques. Due to its ability to influence indirect control targets, stack pointer is a key artifact in attacks. We define SPI as a property comprising of two key sub-properties - Stack Localization and Stack Conservation - and implement a LLVM-based compiler prototype codenamed SPIglass that enforces SPI. We demonstrate a low implementation overhead and incremental deployability, two of the most desirable features for practical deployment. Our performance experiments show that the overhead of our defense is low in practice. We opensource SPIglass for the benefit of the community.},
booktitle = {Proceedings of the 33rd Annual Computer Security Applications Conference},
pages = {116–127},
numpages = {12},
location = {Orlando, FL, USA},
series = {ACSAC '17}
}