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.
replypeople 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?
The big thing for me is the liveness is completely gone or at least can be. In a regular box I can at least poke around at the facilities even if the process dies. I don’t think it’s impossible I just think it’s a hard problem I don’t see emphasized enough.
replyI don't know if anything like this has been built, but I'd imagine you could have the hypervisor capture stack traces / log buffers / core dumps when a unikernel VM crashes.
replyI'm not a security researcher but I know that VMs have been the tool of choice to step through malware execution for at least the past 15 years. I recall coming across ida extensions for it.
replyYeah 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.
replyYou 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.
I’ve always thought there should be a module-level safety property in the type system such that unsafe would be a capability granted by the user’s code.
reply