ctsrd-cheri / cheri-exercises Goto Github PK

View Code? Open in Web Editor NEW

16.0 16.0 6.0 3.99 MB

Learning exercises for CHERI

Home Page: https://ctsrd-cheri.github.io/cheri-exercises/

License: Other

C 83.66% C++ 4.93% Shell 8.02% Makefile 3.39%

cheri-exercises's People

Contributors

Stargazers

Watchers

Forkers

nwf pranayga tariqkurd-repo ninolomata n3op2 josecm

cheri-exercises's Issues

Adjust CHERI binary name in corrupt-a-control-flow-pointer

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.

Something that demos permissions

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?

Bundling up reintroduced CHERI-RISC-V FETT Release 2 kernel vulnerabilities as missions

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.

New constructive exercise adapting a trivial heap allocator

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?

disassemble-and-debug describes (sentry) labels but I see (sealed)

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...

Update examples with gdb 12

ASPLOS'22: New exercise for software adaptation

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.

Document use of -G0 flag

'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?

Error while compiling buffer-overflow.c excersie

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 :)

Adding Morello support

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.

ASPLOS'22: Better "Hello World" exercise

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.

pointer-revocation exercise shouldn't be compiled with -O2

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.

Running built programs could be easier

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.

Adding some brief QEMU CHERI-RISC-V instructions

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.

compile-and-run answers out of sync with exercise steps

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.