3 ms·

This looks encouraging for the security of Mirage unikernels. 8.2 MB is pretty small, but I wonder if it can be even smaller without losing any functionality.

This looks encouraging for the security of Mirage unikernels. 8.2 MB is pretty small, but I wonder if it can be even smaller without losing any functionality. OpenSSL, for example, is ~3 MB. Does that unikernel include symbols and other debugging info? Is there any way to get a breakdown of the object code size for each major component?

jordwalke 11y ago
I'm interested as well, but I can't help but laugh at the fact that we're asking about ways to reduce the size of an 8MB production operating system/stack.
amirmc 11y ago
I wonder that you're forgetting that this is an entire VM. Including all the other bits necessary to function, such as a networking stack, web server, etc. it's not really fair to compare it with just OpenSSL this way. It should really be compared with a full Linux stack+OpenSSL (which is at least one order of magnitude larger, and probably more like two). Having said that, yes there are ways to make it even smaller. We're working on getting the pieces right first.
avsm 11y ago
The 8.2MB can be reduced quite significantly with some compiler improvements. Here's a breakdown: - Native code compilation still includes symbols. Stripping that reduces the size at the obvious cost of debugging ease. - When an OCaml module is touched for a single function, the entire module is included at present. OCaml 4.02.0 included module aliases to make it easier to break down module hierarchies into less monolithic chunks. They work by exposing module equivalence in the signature, and reduced the size of Unix binaries in Jane Street Core by 90% in some cases; https://blogs.janestreet.com/better-namespaces-through-module-aliases/ https://blogs.janestreet.com/better-namespaces-through-modul... - Bytecode (while less performant) can be compressed more easily than native code. We've had DNS and OpenFlow servers that are less than a megabyte in size quite easily when compiled with bytecode. - Dead code elimination requires some whole program optimisation, and currently only works with bytecode via the OCamlClean tool: http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocamlclean http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=oca... . Porting this to native code is on the TODO list, but needs some fiddling with frame pointers in the generated binaries to do a good job. So the overall answer is that reducing the deployed binary size is now a compiler problem, since the unikernel architecture lets us provide it with much more information (configuration files and OS libraries as well as the application logic).

jordwalke 11y ago

I'm interested as well, but I can't help but laugh at the fact that we're asking about ways to reduce the size of an 8MB production operating system/stack.

amirmc 11y ago

I wonder that you're forgetting that this is an entire VM. Including all the other bits necessary to function, such as a networking stack, web server, etc. it's not really fair to compare it with just OpenSSL this way. It should really be compared with a full Linux stack+OpenSSL (which is at least one order of magnitude larger, and probably more like two). Having said that, yes there are ways to make it even smaller. We're working on getting the pieces right first.

avsm 11y ago

The 8.2MB can be reduced quite significantly with some compiler improvements. Here's a breakdown: - Native code compilation still includes symbols. Stripping that reduces the size at the obvious cost of debugging ease. - When an OCaml module is touched for a single function, the entire module is included at present. OCaml 4.02.0 included module aliases to make it easier to break down module hierarchies into less monolithic chunks. They work by exposing module equivalence in the signature, and reduced the size of Unix binaries in Jane Street Core by 90% in some cases; https://blogs.janestreet.com/better-namespaces-through-module-aliases/ https://blogs.janestreet.com/better-namespaces-through-modul... - Bytecode (while less performant) can be compressed more easily than native code. We've had DNS and OpenFlow servers that are less than a megabyte in size quite easily when compiled with bytecode. - Dead code elimination requires some whole program optimisation, and currently only works with bytecode via the OCamlClean tool: http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocamlclean http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=oca... . Porting this to native code is on the TODO list, but needs some fiddling with frame pointers in the generated binaries to do a good job. So the overall answer is that reducing the deployed binary size is now a compiler problem, since the unikernel architecture lets us provide it with much more information (configuration files and OS libraries as well as the application logic).