91–100 of 104 posts
Earlier quoted context omitted.
I think it's impossible, or close to it. Isn't it just another form of the halting problem? https://en.wikipedia.org/wiki/Halting_problem
Well, the alternative is that you limit the set of things you can do, such that you no longer have a Turing machine. But that's certainly less fun, isn't it?
This is really cool, though it looks like the security impact is nuanced. Unikernel plus: A lot of code, including code with vulnerabilities, can disappear. So some vulnerabilities disappear. Unikernel minus: The unikernel and application don't have any security isolation, since the kernel is essentially linked into the appl. As a result, the application has all the privileges of its virtual machine (not the subset t…
There is a downside, if there is a vulnerability the exploit can probably make hypercalls straight to the hypervisor, but a hypervisor can have less of an attack surface than a full OS.
I'd rather see unikernels written in Rust or any other memory-safe language. If we're going to start from scratch with this, let's do it right this time. 70%-90% of bugs seem to be memory-related. Let's end that with a little bit of effort upfront for much fewer headaches in the long-term. https://twitter.com/LazyFishBarrel/status/115341007092920320... https://www.zdnet.com/article/microsoft-70-percent-of-all-se... h…
The entire point of this paper is not to start over from scratch, but to reuse existing software (Linux and memcached in this case), and fiddle with the linker command line and a little bit of glue to link them into a single binary. If you want to start over from scratch using a safe language then see MirageOS. Edit: I don't mean to say you have to use C for the "userspace" part of this. It should be possible -- in f…
Long ago, an OS I worked inside had a tool which took shared library indirect calls, and wired them out so you did not have a nested indirect function call cost, but went direct from the call to the backend without the pass-through the null function mapping into the specific .so library. It made things faster by one layer of the onion skin. Strip, as a UNIX tool removes the textual crap in a debuggable binary, to lea…
On the other hand there is tremendous value in using some well-defined standards along the way so you can benefit from all the debugging, analysis and verification tools that already exist, so such hardware/software co-design is always a balance.
Earlier quoted context omitted.
I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…
True, it's a different picture. It's about how to create a really efficient computing mesh. If unikernels are faster (they start faster, then they run faster), and simpler, and you offload security and topology to kubernetes (or some other orchestration system), then you have a superior system, both in terms of performance and in terms of control.
That is a simplified view, and there are other advantages as well: you probably don't need to exit to your hypervisor quite as often as you do with syscalls, so you benefit from reduced overhead. One disadvantage is that memory allocation is almost static (unless you do ballooning which is tricky to get right), so you "waste" some memory compared to a bare-metal deployment where unused memory can be used for the page cache instead.
Earlier quoted context omitted.
Architecturally, microkernels and unikernels are direct opposites. Unikernels strive to minimize communication complexity (and size and footprint but that is not relevant to this discussion) by putting everything in the same address space. This gives them many advantages among which performance is often mentioned but ease of development is IMHO equally important. However, the two are not mutually exclusive. Unikernel…
Right answer. While a unikernel might be structured to some extent internally into modules, it's basically all linked into a single blob and running in a single address space. Some programming languages may support some kind of PL-level separation, but there is no hardware enforcement. In the case of what Ali is doing because all the code is written in C (it's all Linux, glibc and memcached) there is neither software…
Spin OS (Modula-3), Singularity (Sing#), Midori (M#), TockOS (safe rust).
As far as I know TockOS is the only one I know of which has some form of both PL-level and hardware enforcement of separation, albeit on an MPU rather than a full MMU, PL-level for kernel modules, and an MPU protected userspace.
I at least think it is worth addressing that none of these separation mechanisms are actually mutually exclusive.
Long ago, an OS I worked inside had a tool which took shared library indirect calls, and wired them out so you did not have a nested indirect function call cost, but went direct from the call to the backend without the pass-through the null function mapping into the specific .so library. It made things faster by one layer of the onion skin. Strip, as a UNIX tool removes the textual crap in a debuggable binary, to lea…
get a runtime profile, then optimize the code based on how it will run.
linktime optimization has the compiler output bytecode files, then the optimization happens at the link step where it happens globally across all objects.
Earlier quoted context omitted.
How do they relate to microkernels ? Since last HN post about GNU Hurd, I'm wondering why not try to join this Free microkernel project instead of looking in another kernel's direction ?
Architecturally, microkernels and unikernels are direct opposites. Unikernels strive to minimize communication complexity (and size and footprint but that is not relevant to this discussion) by putting everything in the same address space. This gives them many advantages among which performance is often mentioned but ease of development is IMHO equally important. However, the two are not mutually exclusive. Unikernel…
Earlier quoted context omitted.
Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.
Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.
Earlier quoted context omitted.
The entire point of this paper is not to start over from scratch, but to reuse existing software (Linux and memcached in this case), and fiddle with the linker command line and a little bit of glue to link them into a single binary. If you want to start over from scratch using a safe language then see MirageOS. Edit: I don't mean to say you have to use C for the "userspace" part of this. It should be possible -- in f…
So this would be basically like rumpkernels but with Linux instead of BSD?