Reply To: Security

Thank you; the explanation cleared up a lot for me.

I would be very doubtful about directly exposing a device to applications, the premise of exokernels. Devices (the external thingy itself, not the driver) often have *very* fragile interfaces. Apps in quest of speed are notoriously buggy. There’s no conflict if the device can be assigned to just one process; the process is then both app and driver, and can tinker to its heart’s desire and harm no one but itself. But few devices are as simple and inherently single-user as a card reader these days.

For a shared device, such as a drive, the app may get speed if it does its own driving. However, this exposes all other uses of the device to screw-ups on the part of the app/library/driver. Apps will tend to “just tweak it a bit”, and break everybody else.

There are also issues with global behavior not being the same as local behavior in shared devices. There is a reason for central control of drives: all requests from all apps need to be sorted into seek order instead of request-issue order, or all apps using the drive suffer.

Now if all the library does is what a monolith driver would do, and the apps are trusted not to tinker with it, then the library is a service in the Mill sense, and on the Mill the app no longer must be trusted.

So again, I’m not really seeing much different between the micro- and exo-kernal approaches, at least on a Mill. In the micro, a driver process becomes a fast, cheap, secure service on the Mill; in the exo a trusted library becomes a fast, cheap, secure service. Calling the service a micro or an exo seems mostly a matter of legacy terminology and marketing.

BTW, nothing on the MIT exo site is less than a decade old, so I guess they abandoned the idea. I’d really like to see a paper that tells why.