Slashdot Mirror
Europe Funds Secure Operating System Research
narramissic writes "A Dutch university has received a $3.3 million grant from the European Research Council to fund 5 more years of work on a Unix-type operating system, called Minix, that aims to be more reliable and secure than either Linux or Windows. The latest grant will enable the three researchers and two programmers on the project to further their research into a making Minix capable of fixing itself when a bug is detected, said Andrew S. Tanenbaum, a computer science professor at Vrije Universiteit. 'It irritates me to no end when software doesn't work,' Tanenbaum said. 'Having to reboot your computer is just a pain. The question is, can you make a system that actually works very well?'"
I guess the idea is less about creating an all around well-built system that's pretty secure in practice, and more about creating something that, even if it might have implementation bugs today is fundamentally, conceptually more secure.
I remember submitting some patches to them many years ago when I got Minix working in less that one megabyte of RAM (at the time Minix worked at 1Mb and up) and thinking that it would be nice if it were GPL and if I had the time...
As I recall some guy in Finland did have the time
The sad thing about Windows NT is that the design was pretty good, the implementation was OK, but the default security policy is totally useless. Hooray for backwards compatibility.
Classical Liberalism: All your base are belong to you.
Back when Linus started to write his kernel the debate between monolithic and micro kernels still made some sense. But now more features and drivers are being written for linux and it is getting bigger and more bloated. Functions are being put into modules but that only solves half of your problem because a module can still bring down the kernel.
I think AST was right. Linux can't continue to use a monolithic architecture.
http://michaelsmith.id.au
The real reason there is no security and that we have the monolithic vs micro kernel is that CPUs provide process isolation and not component isolation. Within a process, CPUs do not provide any sort of component isolation. If they did, then we would not have this discussion.
I once asked Tanenbaum (via email, he was kind enough to reply) why CPUs do not have in-process module isolation. He replied:
From: Andy Tanenbaum [ast@cs.vu.nl]
Sent: Ðáñáóêåõ, 1 Öåâñïõáñßïõ 2008 4:00 ìì
To:
Subject: Re: The debate monolithic vs micro kernels would not exist if CPUs
supported in-process modules.
I think redesigning CPUs is going to be a pretty tough sell.
Andy Tanenbaum
But why? I disagree with that for two reasons:
1) the flat address space need not be sacrificed. All that is required is a paging system extension that defines the component a page belongs to. The CPU can check inter-component access in the background. No change in the current software will be required. The only extra step would be to isolate components within a process, by setting the appropriate paging system extensions.
2) The extension will require minimal CPU space and CPU designers already have great experience in such designs (TLBs, etc). Money has been invested for less important problems (hardware sound, for example), so why not for in-process components? it will be very cheap, actually.
Of course, security is not only due to the lack of in-process component isolation, but it's a big step in the right direction...
That was my thought too. If you want to do it right, why not program it in Haskell in the first place. Sure, it might be a little bit slower (not even much actually). But if you go for security, that's not that important anyways.
Now how they will solve the PEBKAC problem, if they end up with a TCPA-like system (in the original intended way of protecting the user, not protecting from the user) and what they will do against tricks like remotely reading computer input, the inevitability of programming errors and bios virii, is a completely different question.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
If you don't understand security it wont matter what language you write in, it will still be crap.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
I'll say this, like I always say it: there is no magic bullet when it comes to security. Even an operating system written from the ground up around security like OpenBSD can be configured incorrectly. Even an operating system written from the ground up around security can have security bugs.
OpenBSD was not written securely from the ground up. It was secured from an inherited codebase over a long, long time. And they have witnessed, time after time, how they combed over the source code for a specific class of bugs, cleaned it, and two versions later the same bug appeared from upstream because the programmer did not fully grok the API he was using.
Just google for strlcpy().
Dropping C is possible.
For example, CoyotOS (http://www.coyotos.org/) uses BitC and aims for the completely proved kernel. I.e. it will be formally proven that its microkernel CAN'T crash or do something wrong.
Or look at QNX, their microkernel used to be something like 12Kb of hand-written assembly code (and so stable that QNX systems literally work for decades now without reboots). The rest can be done using other tools than plain C.