Syscall filtering PoC

[fw-immunant]

This adds some demos and infrastructure used by both those demos and eventually the final runtime. We still need to weld together the pieces in the manner described best in our slides, and the memory-map tracking is still WIP. I would plausibly prefer rewriting part of the memory-map tracking in Rust (memory_map.c) to have access to fancier data structures and more assurances.

[fw-immunant]

There are demos of four runtime components here:

• read-pkru demonstrates reading an inferior's current pkru value with ptrace, which is needed for memory-map tracking.
• seccomp-filter demonstrates the basic structure of the seccomp syscall policy we need; to make this into the MVP for IA2 itself we'll just have to add a clause for each of the 24ish syscalls from Syscall prioritization #233.
• landlock demonstrates the path exclusion we need for /proc/self/mem; try running DENY_PATH=/proc/self/mem ./landlock cat /proc/self/mem and compare to the same with a different DENY_PATH or programs that interact with a specified file in different ways.
• track-memory-map demonstrates memory-map tracking; try running ../rewriter/tests/mmap_loop/mmap_loop_main_wrapped & followed by sudo ./track-memory-map $(pgrep mmap_loop).

[fw-immunant]

memory_map.c currently relies on linear scans of a vector of memory mappings; I would much rather this used a tree so we get sustainable (logarithmic) scaling. We could open-code a simple binary tree in C, but I would be happier using Rust's BTreeMap, something along these lines.

[rinon]

Mostly just minor comments.

Could you add a bit of doc comments (e.g. what you put in the PR comments) for each of the POC main files? Just so someone can tell what a thing should do when they open it.

I like the idea of doing the memory map tracker in Rust, let's do it.

[rinon]

I don't think these comment are necessary, the macros is pretty straightforward.

[rinon]

Might be worth adding a comment after this saying what we would do with this fd?

[rinon]

Have a few comments from last time that still seem relevant. New stuff looks ok, but I'll take another look tomorrow.

[fw-immunant]

I said I wasn't going to clean up this history but I ended up doing it just to make sure the code was all in good shape. As such, merging via rebase rather than squash. Some of the intermediate commits are worth noticing individually as they're changes to our memory-management policy needed to run real programs, which we may want to revisit later.