Slashdot Mirror
GNU Hurd Gets Improvements: User-Space Driver Support and More
jones_supa writes "At FOSDEM 2014 some recent developments of GNU Hurd were discussed (PDF slides). In the name of freedom, GNU Hurd has now the ability to run device drivers from user-space via the project's DDE layer. Among the mentioned use-cases for the GNU Hurd DDE are allowing VPN traffic to just one application, mounting one's own files, redirecting a user's audio, and more flexible hardware support. You can also run Linux kernel drivers in Hurd's user-space. Hurd developers also have working IDE support, X.Org / graphics support, an AHCI driver for Serial ATA, and a Xen PV DomU. Besides the 64-bit support not being in a usable state, USB and sound support is still missing. As some other good news for GNU Hurd, around 79% of the Debian archive is now building for GNU Hurd, including the Xfce desktop (GNOME and KDE soon) and Firefox web browser."
Hopefully it will be launched until 2038.
User Space Drivers != "Improvement".
This is normally called a "defect". Performance design failure and security disaster, in one convenient package!
"Flyin' in just a sweet place,
Never been known to fail..."
Having a project like HURD reflects poorly on Open Source/Free software. It's kind-of emblematic of the major problem with non-commerical software projects; namely, without a central guiding force and a *real* budget, big software projects have a very difficult time getting finished.
Stallman should just kill it. It's pointless.
It also has security advantages, in that drivers don't run in ring zero can't access all memory.
Performance is less of a problem nowadays, because we have fast chips like the Pentium III.
As a rule, I support the idea of making a new OS just for the sake of it. But the important thing to realize most of these will never really get too far as in terms of market share.
Linux success was by luck. It came out when BSD had a lot of serious licencing issues and a big demand for something free, it was developed to a point of being useful fairly rapidly and got a lot of attention. At the same time the 32bit computers for home users were available, and people were jumping on getting a Real OS to do real work on. MS/DOS and Windows 3.1 wasn't a good option, for real work, other solutions just costed way too much money.
Hurd which was made during the same time BSD was having their issues, however it was more of am ambitious project, and couldn't get in during that opening which Linux did.
Now BSD with Free/Open/Net being based on original Unix code, came out of the Licencing mess as an open solution, with some still bad taste in peoples mouth. However they came out a bit more stable than Linux at that time. Where xBSD was being used in a business production settings, for a long time, while Linux matured and took over.
There is a lot of flamewars about GNU being superior then the new BSD license. Saying Linux is proof of this. I would disagree GNU and BSD are both Open Enough standards for general adoption, and Linux success was based on getting in at the right time. Otherwise you would expect HURD to be nearly as possible as BSD is now.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
If you're going to disagree with the whole security community on a security issue, you might want to explain why.
Everybody I know who has any security credentials believes monolithic kernels are a security risk. I have about 20 years of security specialization, and I agree with that view.
If you have an IOMMU, your drivers belong outside kernel address space. If you don't have an IOMMU, you need to get one.
This does not imply that Hurd has done it right. I know nothing about that. It is possible to do it wrong.
With multi cores, and a lack of applications that can thoroughly stress them, one could run the ring 0 kernel mode stuff on 1 CPU, ring 1 on a second, ring 2 on a third and ring 3 on a fourth. So performance doesn't have to necessarily take a hit.
Which one? Mach? Viengoos? Coyotos? L4? Which?
Christ man! Keep your voice down, lest Torvalds and Tenenbaum waken from their uneasy slumber and the Kernel Wars arise anew.
That being said, I tend to agree, and with the speed of processors and RAM these days, microkernels should have a better chance than they did in the past.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Does Mach 3 support having drivers in user space, as opposed to kernel space?
I'm not a developer, but if a Linux driver exists that is written to sit within a kernel, the way it is in Linux, how does one have that driver run in user mode in any OS? I'm somewhat not getting that.
I really think you're wrong. QNX, for example, is an amazing, fast operating system. Microkernels make certain things difficult, but for all of those difficulties there are technical solutions. That HURD can't implement these is not the fault of the microkernel architecture.
I'm sorry, but what? Running drivers as the kernel in ring 0 -- which is the Linux model since it's a monolithic kernel -- is a better security model than user space drivers? How about running as root and writing directly to /dev/mem for memory mapped devices? Is that a better security model, too?
The road to tyranny has always been paved with claims of necessity.
It used to be slow on single core CPUs. But does that have to be the case w/ today's multi-cores? I would think that in the x64, each ring could have its own CPU. They could run the microkernel on one core in ring 0, the OS management on a second on ring 1, and the user mode programs on a third on ring 2, and any VMs in ring 3.
How about subjecting hardware access to the same environment as arbitrary use case and unlimited connectivity options of a user context.
Whoops! Flash exploit just took over my filesystem and network card!
"Flyin' in just a sweet place,
Never been known to fail..."
Have you ever seen this done well? It always looks good on paper.
What about virtualization, and byte-code virtualmachine processes? How many context switches will you do "all the way down"?
"Flyin' in just a sweet place,
Never been known to fail..."
Theory is outdated, and not taking into account past 10 years of experience.
Kernel can be whitelisted. Userspace? Good luck.
"Flyin' in just a sweet place,
Never been known to fail..."
Maybe we're just old, but I thought it was funny.
Comment removed based on user account deletion
Comment removed based on user account deletion
Bringing you the technology of 1997...TODAY!
Chas - The one, the only.
THANK GOD!!!
It also has security advantages, in that drivers don't run in ring zero can't access all memory.
Performance is less of a problem nowadays, because we have fast chips like the Pentium III.
MacOSX and Windows Vista/7 have had this for many years now.
http://saveie6.com/
My understanding is that inter-core communications, while fast, are not as fast as the things a single core can do by itself when only interacting with the level 1 cache. Since the rings of a microkernel would be communicating very frequently and as fast as possible, I'm not sure it would work better.
But more importantly, free software is full of tens of thousands of experiments that didn't seem to make sense at a start. Most wither and die, a few become very big and hugely popular, and even the ones that never see widespread use often serve as a way their authors learn more about the problems they're trying to solve. Maybe the next major revision of the HURD will contain some architectural innovation that improves speed. Maybe some HURD developer, or even just someone reading the HURD source code, will learn something that makes them a better contributor to monolithic kernels. Any benefit is great, nobody is forced to work on it or use it.
Ummm.
Kernel-space drivers have arbitrary access to hardware since ever. There is no way to effectively limit what a ring 0 process has access to - you can only trust them not to meddle where they're not supposed to. A misbehaved or malicious printer driver _can_ ruin your harddrive, or send your bank credentials to a server in Indonesia.
User-space drivers have to request access to hardware resources from the kernel. If a user mode driver requested (and was approved) access to memory range 0x12340000-0x23450000, IO range 0x3d0-0x3e0 and IRQ10 - that's all it can use. Kernel mode driver's requests for those resources are more of a courtesy, not a restriction.
PS: Flash exploits (and even TIFF or .LNK icon exploits) took over filesystems and network cards on Windows just fine. Often thanks to the bugs in a kernel part of graphics driver, win32k.sys. And, yep, that's exactly what moving everything into user space is meant to prevent.
An interesting historical tidbit about QNX is that it was started more or less on the basis of a textbook implementation of a microkernel with real-time features. In the literal sense that the company's co-founders did a class project where they implemented a basic realtime microkernel in an OS class, wondered why there wasn't something similar in the marketplace, and founded a company to sell it.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I think you confused the purpose of IOMMU. It's for restricting the device's memory access. Without IOMMU, it just means that any firmware running on the device's coprocessor can access the main memory unrestricted, meaning that a hacked firmware can root the machine. IOMMU virtualizes device's access to main memory so that doesn't happen. On a machine without IOMMU, you can still run device drivers in user space as long as the kernel sets up the correct memory mapping for the device's PCI address space. That's called memory mapped I/O and has nothing to do with IOMMU.
I once had a signature.
If you want an FOSS version of Plan 9, you should go for Inferno
Oh, shut up.
Windows Vista/7 still haven't even completely separated GUI from ring 0.
Last year had like 5 or 6 vulnerabilities messing with kernel mode to varying degrees simply by trying to display malformed images (and those vulnerabilities were all there at least since WinXP).
My favorite, for sheer WTF-ness, was "display an iframe of a very specific height - get a BSOD". You can find a bunch more by searching for "win32k.sys+(vulnerability|cve)"
I'd think that initially, very few people would be running multimedia, databases, simulation programs on HURD. Compilers/dev, yep. But in real life, very few programs are embarrassingly parallel so as to easily stretch systems no matter how many cores are tossed at them.
I'm not saying that Linux is the be-all, end-all of Free Operating Systems, but after 24 years I think Hurd meets the definition of a failed software project. (And you think Duke Nukem Forever was in development for a while!)
If the developers want to continue developing it, great. But I hope the project is not siphoning off any resources from the FSF's productive work. But I have my doubts as long as the FSF webpages continue to treat Linux as some sort of temporary work-around to Hurd not being available. (And please, just please, let go of the whole GNU/Linux thing... that ship sailed about fifteen years ago.)
User space driver's are one thing, but I'm still waiting for the day whe HURD gets a user.
yes, if you don't mind getting the performance of a Pentium 3 out of your core I7 system whenever that driver becomes the I/o bottleneck. All that extra context switching basically guarantees it will happen regularly.
I can see corner cases for microkernels, like single-purpose/banking/ATM machines where security is paramount. SCADA (though latency might be an issue) might be another good application. However I bet there isn't hardware fast enough to compensate for them in performance critical systems like stock markets.
Gasp, you mean there are architectural security advantages to the way NT is designed vs how Linux is?
Dont let the rest of the community hear you, youll end up tarred and feathered.
Plan 9 works, today. If you want to stay current, you want to go with 9Front however.
---- Booth was a patriot ----
Plan 9 is open too.
On Inferno, has there been any activity at all the last few years from vitanuova? Seems like its totally stagnant at this point. Not flaming, but i cant see anything going on now.
---- Booth was a patriot ----
Your answer sounds like it is nothing more than the regurgitated result of the Torvalds - Tenenbaum debate. Basically it was an argument between the creator of Minix (Tenenbaum) and Torvalds who was inspired to write Linux after playing around with Minix. Torvalds outright called Tenenbaum an idiot and since then we have this single argument as some sort of proof that macrokernels are the holy grail of OS design. And this was over 20 years ago. Though in the end the Linux kernel won because it was available and working.
This ancient argument still poisons peoples opinion about kernel topologies and I still believe there is some hope for microkernels in the area of security. Partitioning in a microkernel is a bit more powerful than jails as Root is not needed to access things that would normally lie in kernel space (e.g. drivers.) Each user can be given their own drivers and user-space outside of the scope of root. Root serves as the true root user, NEVER allowing users any access to it.
Here is a good excerpt from the wikipedia article on microkernels (Hurd uses Mach):
So there you have it. The old argument doesn't appear to hold any water simply because no one has ever undertaken the task of actually building a modern u-kernel based OS for mass consumption. Torvalds is a bit of an egomaniac and a blowhard (though I am very grateful for his efforts) and I doubt he would ever change his opinion until someone actually wruites a u-kernel OS that gives Linux some serious competition. And I doubt it will ever happen because of a great quote I once read:
"Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough. (emphasis mine)
-Eric S. Raymond
This quote is about Plan9, the bell labs "successor" to Unix. It really explains why the sometimes better technology fails to replace existing technology. And it rings true in any area of engineering.
The Amiga microkernel was fast because there was no memory protection. "Kernel" entry consisted of pushing a few registers to the stack and doing a jump. Context switches were similar.
Practically no one is willing to do without memory protection today, and it is likely that achieving Amiga-like context switch times while retaining some kind of memory protection would require significant hardware changes.
Finally! A year of moderation! Ready for 2019?
Now, prove the formal correctness of Linux.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Funny how user space drivers appear to work elsewhere. You can buy higher performance parts, you can't just buy security.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
NT itself is designed pretty well. It's the Win32 layer which is garbage.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
No. Performance is nowhere near as bad as that.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
High frequency trading systems are not a typical example of anything, and should be held as a typical use case for any reasonable operating system. They do things like use custom network hardware which plays fast and loose with the standards, and could easily be compromised if they weren't on a fairly trusted network.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
FTFM
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Given the user is going to be running crap like Java anyway, I don't see that the minor performance hit running a microkernel has is going to make a heap of difference.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
No, you aren't. This was a key point in Liedtke's design for L4.
A "context switch" in a macrokernel OS (on Intel hardware; architectures which support tagged TLBs have a different tradeoff) is a single thing. In L4, the various parts of a context switch are decoupled and the kernel tries very hard to only do as much as it needs to. For commonly-accessed drivers, for example, an IPC round-trip requires only a selector switch (which a macrokernel OS does anyway when it enters and exits kernel mode) and avoids the address space switch completely.
Of course, none of this applies to Mach, which isn't a "micro"-kernel by modern standards.
On the P4, the expensive part was entering and exiting kernel mode; it even dominated address space switching and TLB reload for typical scenarios. I don't know about modern CPUs, but the key point remains: "extra context switching [...] kills performance" is a claim that's hard to prove.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
You've missed that the "beige box is the hard drive" people don't consider something is an operating system until it has a GUI solitaire card game in userspace. To them that card game is part of the operating system simply because it came with the computer. Anything with less than that they consider too archaic to have an operating system. Text screen on a linux server? "How quaint, obviously far less advanced than a TV program recorder" they think.
Thus it's better ignoring them instead of trying to feed them the textbook definition that they are deliberately ignoring.
WTF!
What on earth are you basing that on or are you just punching a strawman? How is he more of an egomaniac than ANYBODY in politics and media?
Yes, I've heard the 'real-time' arguments in embedded but for consumer devices are there tangible benefits to QNX vs Linux?
I'm just thinking, hypothetically, of when Blackberry.com goes under - whether the assets be sold off again to a standalone QNX entity.
Or would it be useful for a company like Samsung re-basing their Android and Tizen efforts on their own proprietary kernel to differentiate their offerings from HTC and LG etc?
Tell that to Google and Facebook.
Yeah. But i386 hardware has more than two rings. The fact that OSes don't use them is what is a problem.
Mach.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Can't anyone do (micro)kernel in ring 0, user services in ring 1, VM hypervisors in ring 2 and VMs in ring 3?
The default mode of Linux use on servers is inside virtual machines (i.e. managed by a hypervisor). Same for Windows.
On the desktop we have Qubes OS and its ability to sequester hardware devices to VMs using IOMMU / VT-d, so the drivers for those devices are effectively contained.
Monolithic kernels have failed at security, so they've been demoted to largely non-security roles, held apart from the core OS like the driver modules of a microkernel.