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?'"
You can. It just requires well defined inputs and outputs and to run on certified hardware. Software, heal thyself? There's a reason self-modifying code is frowned upon. Besides, is kernel reliability really an issue these days? Even the Windows kernel only really crashes when you feed it bad memory.
[FUCK BETA]
Actually, it's not such a bad idea. The concept of putting important components in user-space has been around for a while, and it still has potential w.r.t. reliability. But the real question is: are only microkernel architectures capable of self-healing?
cpghost at Cordula's Web.
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.
This is what I thought when I read the post. It really smells as if the poster, narramissic, had not been around when microkernels and minix were fashionable. And neither was the person to allow for it to show on slashdot.
Let's call the minix discussion flogging a dead horse, until these chaps have come up with something real. If they manage to come up with something that is close to the beauty the idea of microkernels has on paper.
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
I have been trying to answer that question for more than 40 years, and I can say the answer is :: sometimes. The trouble is you need lots of money (i.e. man hours + very good kit + a very well defined problem + lots of testing), unfortunately experience shows that when you get all of that, the system is obsolete by the time you hand it over to the user. It's better to aim for good enough.
nec sorte nec fato
Did SCO confirm it?
Domestic spying is now "Benign Information Gathering"
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.
The folks at Bell Labs who invented Unix and Plan 9 have been doing all that and more since the mid-1990s with Inferno. The core kernel is pure C, which has a bytecode interpreter for the Dis virtual machine, which almost all userspace code runs as, allowing it to run code safely even on CPUs that don't have hardware memory protection. Add to that a neat C-like programming language called Limbo that natively supports primitives inspired by C.A.R. Hoare's Communicating Sequential Processes, full support for distributed processing technology first developed for Plan 9, and you've got a really interesting open source embedded distributed OS that is working today.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
According to the professor, it should soon make Linux obsolete.
Phillip.
A great thread to point out Torvalds hasn't changed much. He's still the same arrogant prick he was back then.
Replying like an inane troll to the professor's insightful and constructive comments. Repeatedly.
Mail after mail, Tanenbaum comes off as an intelligent gentleman, while Torvalds as a frustrated teenager.
He did get one thing right though: it was free, and that made it better.
(Posting AC after modding the parent informative. And yeah, I run Linux.)
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
Too bad that as usual slashdotters talk first. Commercially available microkernel os - www.qnx.com.
This is the best OS I've programmed for. Drivers and network stacks in user space. Develop and debug just like your user-space apps. your driver crashes? No BSOD, no kernel panic, just restart it, it's a user mode process.
No monolithic kernel, no global kernel address space for thousands of people's drivers and modules to screw each other over.
It would be a dream come true if OSS developers would support Minix instead of Linux. Then we'd have a secure robust foundation for OSS software.
Doubt it will happen as most are too short-sighted and quick to spread FUD and deride things that they don't understand (just read the replies on this thread). Turns out they're just as bigoted as MS fanboys or Mac fanboys.
Too bad Linus didn't listen to his professor.
The whole idea is utterly futile, except possibly if the code or the concepts can be reused with another system later on.
After reading the summary, I expect the whole idea is that the concepts will be reused in another system later on.
That would take a loooooong time. First Minix needs to a reach 'gold/stable' release. Then there are the X11 galium noveau and open source ATI driver. Then we are going to need sound support, a port of Gnome and/or KDE 4.8 :') and soundcard and network drivers.
By that time DNF is probably released for Windows NT 7.0 and Wine has kept up with Windows 7 to run it...
Here be signatures
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.
I could go on and on like this. This is how funds are spent without any real gain, not even new concept evolution. Andy, give the EU taxpayers money back!
Lone Gunmen crew.
How is hand-coded assembly a move to a "more secure language" (whatever that means) than C (which is what I was replying to)? Is that not precisely the job for which compiled languages were created?
Regarding CoyotOS and BitC, those are quite interesting references, thank you. It might be a stillbirth, though, since one of the lead guys is leaving the BitCC team. Either way, one could argue that coming up with your own low-level language to develop your own secure operating system is pretty much the only way to be able to "prove" it correct (and "prove" there is in quotes because I doubt they proved LLVM's correctness). Still, from what I read about BitCC, the original point still stands: How intrinsically secure is the languange, in and of itself? What does it have that makes it special? Because all I can find is stuff that makes bugs less likely, like proper bounds testing.
Assembly can be more secure because it doesn't depend on a compiler :)
In any case, 12 Kb of asm/C code is vanishingly small quantity for modern operation systems. For most purposes 12 Kb is the same as 'none'.
"How intrinsically secure is the languange, in and of itself? What does it have that makes it special?"
It allows you to maintain _invariants_, checking them automatically. Including very complex invariants expressed as theorems.
Formal correctness checking is not feasible for large programs, but a formally proved microkernel is quite possible.
You don't need a JIT compiler or an interpreted language to have a secure kernel - you just need a well-designed, type-safe language (which C is not). You can start, for example, from Haskell, as these guys are doing. Haskell is a compiled language, with minimal boxing and, thus, gives all the speed you want without the idiocy of buffer overruns and invalid pointer references. Its performance is within a couple of percent of C.
That is all.
Yup. A dude I knew in college actually modified Linux to put drivers in one of the middle rings as a research project. Seemed like a cool project, and he had working demos of drivers crashing and restarting. I wonder why something like that hasn't caught on.
Actually, I don't know if processor architectures other than x86 have more than 2 levels of protection. That would probably deter a lot of people, and drive them instead to a more general microkernel design. And even then, you can restart a crashed driver but it's often harder to get the device back into a usable state. I actually think having the ability to recover from some driver crashes would be useful, but I think a lot of people would be discouraged by the fact that there would still be lots of unrecoverable crashes (this is the big issue with X11 -- even though the lion's share of a GPU driver lives outside the kernel, when it crashes the GPU is left in an unknown state, and there's tons of state on a GPU. Even if an X crash hadn't left you unable to use your input devices to get back to a terminal you probably wouldn't be able to show it. This is not to say it wouldn't be nice -- logging into the terminal blind to initiate a clean shutdown would be great).