This is partially true...
Posted Nov 18, 2011 7:56 UTC (Fri) by khim
In reply to: There are big difference...
Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
But x86 isn't that good either, so a better machine-language code is needed.
Why? Because you've said so? The only architecture which can realistically challenge x86 is ARM - and it's not all that better security-wise, it's just less power-hungry.
Then there's an absolute dependency on having a garbage collector.
Sorry, but no. Garbage collector is the very opossite from what's needed. History teaches us that again and again. LISP machines bet big on GC, Intel bet big on GC (remember iAPX 432?), others bet big on GC - all these bets failed. Intel had a fall-back plan in 8086 so Intel survived, but all these GC ideas were rightfully forgotten for 10 years. But then architecture astronauts found another victim to push it. It was "bigger success" because Sun just had more money to burn.
Think about yet-another-big-bet-on-GC: Ada. It, too, was designed in times where "first GC push" happened. But Ada developers were not crazy enough to mandate garbage collector: they gave this right to impementers - and that's it. Ada may not be big on desktop today, yet it still used quite heavility where security is important. But guess what: no GC. In most impementations, at least.
You can't have flat RAM, manual memory management and security at the same time (it's a 'choose any two' situation) because it's trivially easy to exploit dangling references.
Right. But the only solution which works is "non-flat RAM" (it many forms). Because for security you need compartmentalization - and this implies non-flat memory model. GC is just not enough. If you have non-flat memory model then you don't need a GC. In fact it hurts security because it makes your design more complex for no good reason.
Then you have to have mandatory boundary checks and limited pointer arithmetic.
Not if you compartmentalized well enough. And since this is required anyway...
E2k doesn't really solve it (as someone who knows a few folks from MCST - E2k doesn't really solve ANYTHING). It has hardware tagging for pointers, so all pointer arithmetic instructions are privileged operations.
Not all. It's pointer includes memory address, size of region and offset in that region. This is enough for compartmentalization.
That can be used as a hardware assist for low-level secure OS, but in itself it's certainly not enough.
Sure, you still need to design you software carefully - even with hardware support. But to do that you need right principles. GC and managed code will not work because they bring complexity to the very piece which must be superuberrobust.
And NaCl still relies on hardware memory protection to contain untrusted code
It only relies on NX bit. And while yes, there were cases where NX bit was handled incorrectly in hardware they are much less common then errors in GC and JIT.
So to recap this, I believe that a future OS is going to use software-enforced isolation. Probably aided by a more suitable hardware architecture than x86. It most probably won't use bytecode format of current virtual machines, but it would functionally similar to them.
I'm pretty sure architecture astronauts will try to push something like this. They will find another suitable victim with billions to burn and we'll have yet another fiasco. Complete with grand promises, industry-wide madness and disappointment at the end. But they will need to wait about 10 years till they'll try that: people are fed up with astoronautics for the moment.
to post comments)