Interesting to me that the author is seeking to add this into the unikernel. I was playing with the PHP Rumprun unikernel before trying to make it immutable such that the unikernel is based on one file structure only (surprise: most PHP applications assume they can write to a FS).
I like the idea that my deployment is closer to being idempotent for a number of reasons, one of which is security.
Can you expand on that idea? For Rumprun, it's not very many minutes of work to set things up so that you have a lower readonly file system layer (immutable across restarts) and then a memory file system on top of that (for purposes of applications insisting to modify "readonly" files). But, of course, it's not very many minutes only if you know the ins and outs of the backend system, and that's not the level of usability what we're aiming for. So, if writing "readonly" files is a widely desired feature, we should probably somehow support it as part of the general infrastructure in Rumprun so that it just works even if you don't know the ins and out of the underlying system.
The core issue with PHP is that most applications think they can just drop files in all sorts of places depending on what page was requested and to what user is logged in and what the state of the database was... and it always depends on what the application is. Some of these files are user uploads, logs, or cache for performance sake (more conflicting here is that PHP will cache op codes into memory based on the filesystem structure).
It's also pretty common to see exploits where an attacker injects code into a PHP file, so making a subset of this immutable would be a big win IMO when talking to business and IT about the list of reasons I would use this in production.
Author here. My goal is to (eventually) host a toy key:value store on top of a unikernel. So the KV store would need to persist data to a writable file system. It's great when you don't need to alter state and the unikernel can be immutable (baking config into code ala Mirage, etc)...but something like a KV store can't get away with that.
But, the KV store + unikernel is mostly for fun, so may not be the most practical of real-world ideas anyway :)
Wouldn't something like Irmin work well with this (assuming you can fit the working set into memory, which I think might be a requirement of Irmin's design)?
Have you been able to also run it with KVM - I wonder why -no-kvm is passed to qemu.
As you tried ext4 I think it failed as netbsd is not having drivers for it.
