ctsrd-cheri / cheri-exercises Goto Github PK
View Code? Open in Web Editor NEWLearning exercises for CHERI
Home Page: https://ctsrd-cheri.github.io/cheri-exercises/
License: Other
Learning exercises for CHERI
Home Page: https://ctsrd-cheri.github.io/cheri-exercises/
License: Other
The 'corrupt-a-control-flow-pointer' instructions state:
Compile buffer-overflow-fnptr.c with a RISC-V target and binary name of buffer-overflow-fnptr-riscv, and
a CHERI-RISC-V target and binary name of buffer-overflow-fnptr.
The last binary name should be buffer-overflow-fnptr-cheri
for consistency with the other exercises.
We have quite a few of the development exercises demonstrating capability integrity, but not with permission deficits. Maybe a type confusion between a char* and void*(void) to show you need execute? Or maybe an example that forces actual const-ness using read-only capabilities?
DARPA has asked us to consider bundling up our reintroduced kernel vulnerabilities in FETT Release 2 (pure-capability kernel) as missions. This will presumably consist of short sections for each of the missions with a brief description and pointer to the FreeBSD security advisory, and ideally reintroduction commit in GitHub.
As we discussed today, it would be very nice if there were a "constructive" exercise, say, adapting a trivial heap allocator to CHERI, with the point being to add the csetbounds (and ponder crrl and maybe cram) and the non-monotonic reach to metadata. This may be too long for ASPLOS'22 proper (or too much work to develop in time), but I think @davidchisnall at least indicated some willingness to write up a little C++ allocator for this purpose?
Step 12 of 'Disassemble and debug...' states
Notice that some capabilities are labeled with (sentry)
but I only see entries labeled (sealed)
in the register file:
(gdb) info reg
ra 0x101b1a 1055514
sp 0x3fffcfff70 274874761072
gp 0x0 0
tp 0x40798040 1081704512
t0 0x101860 1054816
t1 0x1e 30
t2 0x7000000000000000 8070450532247928832
fp 0x402efc64 1076821092
s1 0x3fffeff790 274876856208
a0 0x1004ef 1049839
a1 0x10 16
a2 0x3fffcfff70 274874761072
a3 0x101af4 1055476
a4 0x3fffeffd03 274876857603
a5 0x0 0
a6 0x1f 31
a7 0x10 16
s2 0x3fffeff770 274876856176
s3 0x0 0
s4 0x0 0
s5 0x0 0
s6 0x0 0
s7 0x0 0
s8 0x0 0
s9 0x0 0
s10 0x0 0
s11 0x0 0
t3 0x0 0
t4 0x1 1
t5 0x40 64
t6 0x0 0
pc 0x402efc72 1076821106
cnull 0x0 0x0
cra 0xd1172000080180060000000000101b1a 0x101b1a <main+38> [rxR,0x100000-0x104000] (sealed)
csp 0xf17d000003fb1ffd0000003fffcfff70 0x3fffcfff70 [rwRW,0x3fbff00000-0x3fffd00000]
cgp 0x0 0x0
--Type <RET> for more, q to quit, c to continue without paging--
ctp 0xd17d00000055800d0000000040798040 0x40798040 [rwRW,0x40798010-0x4079a2a0]
ct0 0xd1172000000180060000000000101860 0x101860 <_start> [rxR,0x100000-0x104000]
ct1 0x1e 0x1e
ct2 0x7000000000000000 0x7000000000000000
cfp 0xf11720000b79c43e00000000402efc64 0x402efc64 <printf> [rxR,0x4010e000-0x40778000] (sealed)
cs1 0xf17d00000635b7940000003fffeff790 0x3fffeff790 [rwRW,0x3fffeff790-0x3fffeff8d0]
ca0 0xd11520000540c4eb00000000001004ef 0x1004ef [rR,0x1004ef-0x100505]
ca1 0x10 0x10
ca2 0xf17d000003fb1ffd0000003fffcfff70 0x3fffcfff70 [rwRW,0x3fbff00000-0x3fffd00000]
ca3 0xd1172000080180060000000000101af4 0x101af4 <main> [rxR,0x100000-0x104000] (sealed)
ca4 0xf17d000007447cf40000003fffeffd03 0x3fffeffd03 [rwRW,0x3fffeffcf0-0x3fffeffd17]
ca5 0x0 0x0
ca6 0x1f 0x1f
ca7 0x10 0x10
cs2 0xf17d000005e5b7740000003fffeff770 0x3fffeff770 [rwRW,0x3fffeff770-0x3fffeff790]
cs3 0x0 0x0
cs4 0x0 0x0
cs5 0x0 0x0
cs6 0x0 0x0
cs7 0x0 0x0
cs8 0x0 0x0
cs9 0x0 0x0
cs10 0x0 0x0
cs11 0x0 0x0
ct3 0x0 0x0
ct4 0x1 0x1
ct5 0x40 0x40
ct6 0x0 0x0
pcc 0xf11720000379c43e00000000402efc72 0x402efc72 <printf+14> [rxR,0x4010e000-0x40778000]
ddc 0x0 0x0
cap_valid 0x8e80381b 2390767643
This could also plausibly be a user bug rather than a documentation bug, but I think I followed the instructions...
As we talked about today, it would be very nice to have an additional, less adversarial exercise focused on the kinds of common adaptations needed to port C to CHERI C. Ideally something with N sins all found by the compiler and then 1 found only at runtime and 1 (possibly the same) found by the sanitizer.
'interobject-buffer-overflow' specifies that -G0
should be added to the compiler flags. Why is this flag needed? Should it also be used when compiling code samples for the other exercises?
Hi!
I have build my local environment with cheribuild script:
cheribuild.py cheribsd-riscv64-purecap -d
[...]
cheribuild.py cheribsd-sdk
All the steps seem to be setup properly.
I am trying to compile exercise 3.1 from https://ctsrd-cheri.github.io/cheri-exercises/missions/buffer-overflow-control-flow/index.html however I am getting an error indicating that some symbols are unidentified:
./ccc riscv64 buffer-overflow.c
Running: ~/cheri/output/sdk/bin/clang -g -O2 -target riscv64-unknown-freebsd --sysroot=~/cheri/output/rootfs-riscv64-purecap -fuse-ld=lld -mno-relax -march=rv64gc -mabi=lp64d -Wall -Wcheri buffer-overflow.c
buffer-overflow.c:52:5: warning: implicit declaration of function 'main_asserts' is invalid in C99 [-Wimplicit-function-declaration]
main_asserts(buf, fptr);
^
1 warning generated.
riscv64-unknown-freebsd-ld.lld: error: undefined symbol: btpmalloc
>>> referenced by buffer-overflow.c:49
>>> /tmp/buffer-overflow-e03b0a.o:(main)
>>> referenced by buffer-overflow.c:50
>>> /tmp/buffer-overflow-e03b0a.o:(main)
riscv64-unknown-freebsd-ld.lld: error: undefined symbol: main_asserts
>>> referenced by buffer-overflow.c:52
>>> /tmp/buffer-overflow-e03b0a.o:(main)
riscv64-unknown-freebsd-ld.lld: error: undefined symbol: btpfree
>>> referenced by buffer-overflow.c:66
>>> /tmp/buffer-overflow-e03b0a.o:(main)
>>> referenced by buffer-overflow.c:70
>>> /tmp/buffer-overflow-e03b0a.o:(main)
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
It doesn't matter if I use the CCC script or not or if I compile for riscv64-purecap or riscv64
Other projects, for example print-pointer.c ( https://ctsrd-cheri.github.io/cheri-exercises/exercises/compile-and-run/index.html ) work as intended.
Any help will be appreciated :)
On the whole, the exercises and missions in this document are portable across CHERI architectures. However, the cross-compilation tools/instructions and sample answers are specific to CHERI-RISC-V. Adding Morello variants, once the world is ready, would be quite useful.
The present "Compile and run" and "Disassemble and debug" exercises immediately jump into ABI. We'd like something a little gentler, like an address-taken stack buffer, to warm people up to the changes in generated code. We can then tell them about the linker/loader conspiracy to bound globals.
ccc
adds -O2
to the default args, but the pointer revocation demonstration doesn't work quite right with -O2. In particular, the assignment obj1->arg = (uintptr_t)obj1;
seems to be optimized away by the compiler, though obj1->fn = fn1;
remains:
int
main(void)
{
struct obj *obj1 = calloc(1, sizeof(*obj1));
fprintf(stderr, "Installing function pointer in obj1 at %#p\n", obj1);
obj1->fn = fn1; <-- not optimized away
obj1->arg = (uintptr_t)obj1; <-- optimized away
I can't explain this behavior, but compiling instead with -O0
produced binaries that behaved as expected.
Both Peter and I think that running QEMU and setting up a shared filesystem between guest and host could be further streamlined.
I was just using the cheribuild alone route, Peter was using the docker.
I think we should ship the docker image with cheribuild, and an appropriately configured cheribuild config to pick up the compiler/qemu etc. Then people can use the run-riscv-purecap target, which sets up an smbfs server for you. We should also probably include documentation in this repo for the cheribuild command, and the command to execute in the guest to mount the directory.
It would be useful to add some brief Qemu build and execution instructions to the cross-compilation page, so that these are more easily used outside of the FETT environment. This shouldn't be a full CHERI guide, but a couple of cheribuild command lines and a brief instruction or two about logging in, etc., should do the trick, since we assume the reader is pretty clued up already with respect to systems programming and architecture before they start.
I would expect to see:
2. Expected output:
# ./print-pointer-riscv
size of pointer: 8
size of address: 8
4. Expected output:
# ./print-pointer-cheri
size of pointer: 16
size of address: 8
6. Expected output:
# ./print-capability
cap length: 4
...
What is currently listed for solution 6 doesn't seem to follow the listed steps of the exercise.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.