[cap-talk] cap-talk Digest, Vol 66, Issue 46

[Leo Meyerovich]

Before anyone is insulted, I should clarify that I am both a (browser) 
security and performance nut :) Going back... 

> I disagree with this statement 
> - With an OS limited to type safe /Memory safe languages with language based
> isolation , increased reliability and security it's not a case of not liking
> the structure it just seems like it's a waste of resources for zero gain.
>   

Memory and type safe languages, historically, have been victim to 
attack. The problem is exasperated by their egg-like design: hard shell, 
gooey insides. Using them eliminates sources of error.. but there is 
still a sizeable TCB that has bitten us in practice. Minimizing it is an 
active research area, not a solved problem.

> - I think every day users originally hated this architecture . MS dragged
> them screaming into NT/Windows 2000 which forced HW upgrades etc. But now
> it's the norm. Slow OS  even if more reliable or secure fail in the
> marketplace (except for niches) eg JavaOS/Workplace OS/Taligen.
>   

Users hate most change. Further, going directly against the described 
sentiment, the most recent incarnation of partitioning  was essentially 
one of the two main features of Google Chrome. Finally, for the intended 
mainstream use case, this design ended up being correct in trading off 
performance for reliability and relying upon Moore's Law to make up the 
difference. I wouldn't say it is safe, but nor is 'verified' hardware -- 
not a useful statement. We're actually still seeing new benefits with 
the shift to multicore.

> - It doesn't help when critical components like device drivers fail .
> Forcing you into either 
> 	a) accepting the lower reliability , 
> 	b) Go the Mach3/Minix way and suffer a big performance hit. (yes L4
> made some gains but the Increasing cost of memory compared to CPU  favours
> monolithic structures in the long term using HW mem protection) 
> 	c) Isolate most drivers . But grouping critical things into a single
> user space defeating the isolation benefits (OSX)
>   

Don't throw out the baby with the bathwater. You missed what's actually 
being done: special casing the special case. MS is heavily invested in 
at least two low-level verification projects that are reaching 
surprising maturity (and are already being used internally, at least). 
There are other approaches as well; drivers don't invalidate the overall 
design.

Finally, first, as in my original message, for some domains (say where 
you'd consider running TinyOS), the considerations change considerably, 
though I suspect economic incentives dominate (with implications in 
kernel dev time, app dev time, app perf). Second, abstraction/isolation 
layers do not preclude ocap reasoning; it simply argues for partitioning 
your system into a tree where every child node is separated from the 
parent. Every node, if you wanted, could be an ocap system. What it 
means for going up/down the tree -- an end-to-end ocap system -- I don't 
know, but as this architecture reflects OS design for PCs, I'm guessing 
someone here does.

- Leo