4 ms·
You might enjoy reading my response to that: https://nanovms.com/dev/tutorials/assessing-unikernel-security https://nanovms.com/dev/tutorials/assessing-unikern
by eyberg 6y ago
You might enjoy reading my response to that:
https://nanovms.com/dev/tutorials/assessing-unikernel-security https://nanovms.com/dev/tutorials/assessing-unikernel-securi...
- MaxBarraclough 6y agoI'll be frank: that article strikes me as weak sauce. It's coy about the identity of the paper it discusses. It's there in the title, and nowhere else, as if that's enough for it to be clear to the reader. Beyond this, the responses offered are not strong. It makes good sense to compare unikernels against conventional GNU/Linux. It's the standard configuration, and it sets the bar. Describing this as a pyschological hump isn't a sensible response. I don't know what advances to things like the networking stack is meant to refer to. The article should be clear and explicit about what part of the paper this is responding to. As it stands it looks like a straw-man. The response to unikernels are un-debuggable makes little sense. Someone can work on a debugger while claiming the current state of debugging is poor. No contradiction there. Downplaying the significance of Data Execution Prevention isn't a convincing defence. Downplaying the significance of ASLR isn't a convincing defence. These are valuable security measures. This excerpt from the conclusion seems to indicate a reluctance to take security concerns seriously at all, as if a security analysis is an emotional attack: there's a thousand little kids out there wanting to crap on anything they can. Security bugs are bugs at the end of the day and all one has to do is look at any random popular github to understand how many bugs we as humans create.