As mentioned before on this topic. What about debug ability? An application overflow now corrupts part of the network stack.

In an oxide episode there were some mentions of reading off data lines but I just don’t think that’s practical.

The reduced attack service is cool but not at the expense of my visibility and liveness of the system

this question always comes up. I personally think the status quo is pretty weak here. I have certainly added a gdb stub to a unikernel before, but that apparently given that it was never used it wasn't the right answer.

people always talk about losing the excellent debugging facilities that linux gives you. if a service crashes in a big cloud environment what is that you do now that works so well. do you think its intractable to implement that in a single-process kernel?

Yeah that's generally the argument for using a managed runtime (like Ocaml in MirageOS's case, or I could see Go or even the JVM fitting here) for these kinds of things. Running a VM which has no pointers, memory access etc primitives, and is garbage collected etc direct on "metal" gives more peace of mind about that sort of thing.

You could make the argument that Rust w/ its memory safety is a candidate, but w/ Rust it's still entirely possible and fairly easy to break out of that. And Rust/Cargo applications have a habit of using a bazillion third party deps that you then need to keep a close eye on.