topo: add guard pages around workspaces

[alpeng-jump]

Fixes #989. Prevent overruns from stepping into another workspace by adding guard pages around each workspace.

[mmcgee-jump]

I don't think this is the direction to go with this, it adds 2GiB of mlocked memory overhead to every wksp which is over like 40GiB. These pages need to stay unmapped. You can make them without paging in by doing mmap(MAP_FIXED) around the prior allocation, not making it bigger.

[asiegel-jt]

It seems like workspaces using gigantic pages will naturally be adjacent in vm space. I suspect allocating guard pages will often fail.

[mmcgee-jump]

I don't think that's true? Workspace addresses are random, due to another security change.

[mmcgee-jump]

Yeah, this happens in sequence as well, so the other workspaces won't be allocated yet anyway. They will randomize their address until it succeeds.

[mmcgee-jump]

.

[mmcgee-jump]

Unless I'm doing something wrong this change doesn't appear to work. I checked it out and ran it and there are no guard pages around the workspaces. You can see this by running, eg the below,

So it doesn't work but it also silently fails, which is not what we want for security sensitive changes. I would tidy this up and make the error handling clearer and more explicit.

[mmcgee@emch-ossdev-firedancer8 firedancer]$ sudo cat /proc/234938/maps
00400000-05573000 r-xp 00000000 fd:01 135427458                          /home/mmcgee/firedancer/build/native/gcc/bin/fddev
05773000-0594b000 r--p 05173000 fd:01 135427458                          /home/mmcgee/firedancer/build/native/gcc/bin/fddev
0594b000-05954000 rw-p 0534b000 fd:01 135427458                          /home/mmcgee/firedancer/build/native/gcc/bin/fddev
05954000-0861c000 rw-p 00000000 00:00 0 
182edfc00000-182edfe00000 rw-s 00000000 00:2f 1993885                    /mnt/.fd/.huge/fd1_metric_in.wksp
23fd1bc00000-23fd1be00000 rw-s 00000000 00:2f 1993892                    /mnt/.fd/.huge/fd1_verify.wksp
3c4740000000-3c4780000000 r--s 00000000 00:30 2011142                    /mnt/.fd/.gigantic/fd1_quic_verify.wksp
49b3c0dff000-49b3c0e00000 ---p 00000000 00:00 0 
49b3c0e00000-49b3c1600000 rw-s 00200000 00:2f 2074106                    /mnt/.fd/.huge/fd1_stack_verify1
49b3c1600000-49b3c1601000 ---p 00000000 00:00 0 
6acac0000000-6acb00000000 rw-s 00000000 00:30 2011143                    /mnt/.fd/.gigantic/fd1_verify_dedup.wksp
7f2298e00000-7f2299600000 rw-p 00000000 00:00 0 
7f22997b3000-7f22997ca000 r-xp 00000000 fd:01 138665019                  /usr/lib64/libgcc_s-8-20210514.so.1

[mmcgee-jump]

.

[mmcgee-jump]

I'm also realizing, on the rare occasion that workspaces end up adjacent this code would just fail anyway, rather than making guard pages, since it wouldn't be able to grab the region.

You probably will need a with_guard flag to fd_wksp_create that makes sure the grabbed region has enough padding on either side to avoid this.

[ripatel-fd]

Linux 6.13 has a new feature for this.

       MADV_GUARD_INSTALL (since Linux 6.13)
              Install a lightweight guard region into the range specified
              by addr and size, causing any read or write in the range to
              result in a SIGSEGV signal being raised.