..

Posts/OperatingSystem

@@ -98,10 +98,12 @@ The idea is straightforward: use a hypervisor, and its hardware
 abstractions (virtualised input/output and network device), and execute the
 OCaml runtime directly on it.  No C library included (since May 2015, see [this
 thread](http://lists.xenproject.org/archives/html/mirageos-devel/2014-05/msg00070.html)).
-This OCaml-based virtual machine runs in kernel space (this is bad, but
+This OCaml-based virtual machine runs in kernel space (which is bad, but
 [this article](https://matildah.github.io/posts/2016-01-30-unikernel-security.html) shows
 why it isn't too bad) for now, and
-consists of the required libraries only.  This website is 16MB in size (and I didn't even bother to strip yet), which
+consists of the required libraries only.
+If we assume that the memory management of the OCaml runtime cannot be circumvented (by malicious code), there is no need for isolating the memory space even further.  I think that an interesting approach is to use capabilities in a way [barrelfish](http://www.barrelfish.org/) does.
+This website is 16MB in size (and I didn't even bother to strip yet), which
 includes the static CSS and JavaScript (bootstrap, jquery, fonts), [HTTP](https://github.com/mirage/ocaml-cohttp), [TLS](https://github.com/mirleft/ocaml-tls) (also [X.509](https://github.com/mirleft/ocaml-x509), [ASN.1](https://github.com/mirleft/ocaml-asn1-combinators), [crypto](https://github.com/mirleft/ocaml-nocrypto)), [git](https://github.com/mirage/ocaml-git/) (and [irmin](https://github.com/mirage/irmin)), [TCP/IP](https://github.com/mirage/mirage-tcpip) libraries.
 The memory management in MirageOS is
 straightforward: the hypervisor provides the OCaml runtime with a chunk of memory, which