[Haskell-cafe] OS design & FP aesthetics

[Tony Finch]

On Mon, 18 Jun 2007, Creighton Hogg wrote:
>
> Okay, but these don't seem to really be design flaws so much as the
> inevitable results of age and the need for backwards compatibility.  I'm
> looking more for technical problems that you would want to see fixed in our
> magical UberOS.

I don't think I'll have much to say about Haskell or FP in general here,
so this is way off-topic. In particular, I'm skeptical about relying on
language guarantees as the basis of OS security, because that tends to
limit the scope of your platform - you still want to support legacy C
applications. Perhaps you can use typed assembly language techniques to
check machine code before running it... dunno.

Anyway:

(1) Security partitioning. Current OSs are based on timesharing security,
where users are protected from each other, but any process owned by a user
can do ANYTHING to any other process owned by that user. This makes you
utterly vulnerable to viruses, since if an attacker has compromised the
user of a single user machine, they've effectively compromised the
machine, whether or not they have got root.

Furthermore, users don't have enough privilege to create new security
partitions (i.e. new users), which would allow them protect themselves
against untrusted code. As others have mentioned, a capability-based
system is the ideal to aim for.

(2) Unix has an assumption that disks are fast and the network is slow, in
that you can't do something else while waiting for data from the disk, but
you can with data from the network (using select() etc.) There are some
AIO APIs that fix this problem, but they are disgusting and don't fit in
with the network APIs. There's also the problem of paging which means that
memory can unexpectedly take 10ms instead of 10ns to access.

(3) The network APIs assume that memory bandwidth is cheap and that it
makes sense to copy data from userland buffers to kernel buffers. It would
be faster if buffers were sharable. There are some zero-copy APIs (e.g.
sendfile), but they are not general. Cunning tricks to retro-fit zero copy
onto the existing API depend on page table hacks and often have
unexpectedly bad performance in some situations.

(4) The system-call-as-function-call model assumes that system calls take
negligible time. This is not true for filesystem calls, e.g. stat, open,
etc. especially ones that aren't supported by an AIO API. Even fast system
calls uncur the cost of two context switches. A better model is
system-api-as-network-protocol, in which userland can send a bunch of
requests to the kernel in one system call, and get the results back as and
when they are available. There are some APIs like this already in the
event-handling area, e.g. kqueue and epoll, but they are not general. The
Linux "syslets" idea is heading in this direction.

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
HEBRIDES BAILEY FAIR ISLE: EAST OR NORTHEAST 4 OR 5, OCCASIONALLY 6. SLIGHT TO
MODERATE, OCCASIONALLY ROUGH. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.