Add Copy on Write support on the host for nanvix

[jsturtevant]

fixes: #1334

Hyperlight's map_file_cow creates READ+EXECUTE memory regions (no WRITE). Nanvix's VFS/FAT32 layer requires writable memory for the RAMFS image. Currently, Nanvix works around this by copying the entire RAMFS image from the read-only MMIO region to a heap-allocated buffer on Hyperlight (see nanvix/nanvix#1729).

[syntactically]

I'm not totally sure this is sound, especially as we move to support multi-vcpu guests with #1112. There is code in e.g. crashdump and gdb that assumes these regions can be read from the host side at all times without it being racy. There's generally a lot of code that assumes that these are readonly, because they have been since they were added. I was more OK with #1271 being merged quickly as a temporary stopgap because the assumption that the snapshot was readonly had only just been introduced, and so making sure that code didn't depend on that when the nanvix-unstable feature was enabled was relatively easy. And, it used the same shm lock APIs that were used for the shared mem in the past / are used for the scratch mem now.

I also fear that this will lead to people trying to use mapped regions to sneakily do shared memory i/o with the guest outside of hyperlight itself, which is something that we had explicitly intended to disallow for safety and security reasons. Compare to #713, where we explicitly avoided creating a similar feature.

[jsturtevant]

I was more OK with #1271 being merged quickly as a temporary stopgap because the assumption that the snapshot was readonly had only just been introduced, and so making sure that code didn't depend on that when the nanvix-unstable feature was enabled was relatively easy.

It is still a pretty large lift to move nanvix into a model where we can use the CoW work here. I believe that we need to do that to remove these changes and to improve the over all performance.

And, it used the same shm lock APIs that were used for the shared mem in the past / are used for the scratch mem now.

I don't follow this how this helps.

I also fear that this will lead to people trying to use mapped regions to sneakily do shared memory i/o with the guest outside of hyperlight itself, which is something that we had explicitly intended to disallow for safety and security reasons. Compare to #713, where we explicitly avoided creating a similar feature.

I did just build a prototype that does this. Weren't we mapping files previous in CoW? What prevented this before? Another reason to move Nanvix to CoW. This would require a cooperating guest and host and using the "unstable" feature.

@simongdavies @danbugs Do you have thoughts on other options here?