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.
I have been working on Hurd for quite a long while (made contributions to the kernel years ago), and I would like to bring up the pertinent point that Beta sucks!
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..."
Does it run Beta?
Does it?
Yes, but commenting doesn't work.
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.
Hurd is based on a failed Computer Science Pipe Dream, the Micro Kernel. Why would anyone embrace something that is so slow? (except to write a phd thesis)
No, but it finally runs Duke Nukem Forever.
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.
Liedtke proved that if you design your kernel with high-performance IPC in mind, the cost is negligible, plus you get the security BENEFIT of not running your drivers in Ring-0 (which gives them full access to the address space).
Not to say that Hurd fully takes advantage of these insights.
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.
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?
Have you heard about the Hurd?
Well, everybody knows that the Hurd is a turd!
Hurd Hurd Hurd
The Hurd is a turd
Hurd Hurd Hurd
The Hurd is a turd
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.
Sorry but it doesn't matter with Server-Client architecture operating systems are drivers located in User Space or in Kernel Space as long they are separated from the microkernel itself.
The whole reason why Server-Client architecture exist was to avoid problems what the Monolithic operating system architecture had with device driver or operating system function crashing causing whole operating system (kernel) crashing and so on the whole software system to crash at that moment.
But as we can see, Monolithic OS architecture isn't a problem like Linux kernel can proof that whole operating system can be a monolithic but still modular in binary level and be very stable, secure and fast.
Hurd would have been nice operating system if they would have got their microkernel working right and they would not chose to use Server-Client architecture for it instead superior Monolithic architecture what Linus Torvalds chose to Linux operating system (went on that time under different name before it got renamed as Linux as everyone knew it afterwards and before GNU fans tried to claim Linux is a microkernel and not a monolithic).
He said "kernel" and not to "microkernel". So he means the whole HURD operating system and not just its one of the many microkernels HURD has included.... this in sense that he claims HURD is a kernel like monolithic operating systems are instead HURD is server-client and so on just operating system and not a kernel because it has a microkernel and servers.
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..."
Straw Man
Then it's simply less efficient in terms of power.
Comment removed based on user account deletion
Comment removed based on user account deletion
Hmmm, should I install Hurd or Plan9? .....
Bringing you the technology of 1997...TODAY!
Chas - The one, the only.
THANK GOD!!!
Wouldn't this make a good automated testing layer for kernel modules?
Are you only running little toy apps? Anything involving multimedia, databases, compilers/dev tools, etc. can easily stress 8 and 16+ core systems. Maybe if all you run all day are Twatter/Friendface and fart apps this might be true, but or anyone actually using a computer can easily stress multi-core systems.
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.
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.
Shazbot! We ran into some trouble getting the comments.
Try again... na-nu, na-nu!
WTF IS THIS GARBAGE?
Fuck Beta!
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.
GNU?Hurd will be at the same level of hardware support as Windows 95 in a few years
Politics is Treachery, Religion is Brainwashing
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.
These guys are fast!
IDE AND AHCI. wow!
You are still dealing with extra context switching that kills performance. Modern PCs depend on DMA for performance, especially for devices with huge IO and low latency requirements (GPUs for instance).
Great, so we can regress to 1996 era performance on a core i7? For what purpose? To compensate for the stupidity that is having things like scriptable browsers? It would be a lot easier and faster to quit building these endless stacks and focus on making programs for single uses. The browser should be used to render static html.. Dynamic stuff happens on the server. Now you get security AND performance.
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.
Why is it that so many non-coders have so many opinions as to what coders should do with their time? It's as if you think that we are somehow here to scratch your itches, rather than our own.
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.
That seems unlikely.
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});
OS X is a microkernel.and appears to be doing quite well.
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});
Interesting how many people come up with negative arguments against Hurd & microkernels in general, obviously without having any experience in system design at all, simply citing the same ancient crtitisms that were raised 20 years ago. Just to make this clear: performance is not the issue with microkernels today. You probably even have a cell phone that is running a microkernel as hypervisor below your actual advertised OS like Android, Symbian, Linux and more. You are not seeing it, and the vendor did not tell it, but it's there. Running on a lousy weak ARM CPU. You have a fruit phone instead? Then you are running the XNU microkernel instead.
Negative prejudices, floating around in the mass of people, are probably THE biggest problems an alternative system like Hurd has, that prevents it for being accepted by people, being adopted by new developers and thus against allowing it to grow.
Most of you are probably fine with a monolithic kernel like Linux ... today. There were also times where people were fine with systems that did not provide memory protection & virtual memory. They were simple, they were fast, so why do we need fancy stuff? But fact is, our systems are growing constantly and stability, complexity, timing and security issues already reached a level where they become hardly satisfiable with monolithic kernels. Nobody today would consider building a huge ferry or supertanker where a tiny leak could float the entire boat. But that's eactly what you got with monolithic kernels.
I'm using Linux, developed device drivers on it for years, but I do think that its design is not able to fulfill requirements soon to come. Especially the current tendency from user based isolation & protection over to task and program based isolation & protection is simply not feasible with a monolithic kernel.
So I am very happy to give Hurd a chance. I hope you too.
MySQL/MariaDB is crap and a waste of developer effort.
Seriously do yourselves a the rest of the world a favor and stop implementing applications using that crap. There is no place for it. Its not a good as an enterprise even a single application database and its not a good embedded database either. But ignorant assholes keep implementing applications in it.
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?
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
No, they aren't. They are a security risk amplifier. But you still need a concrete vulnerability to get an actual security problem. Likewise, the C programming language is not a cause for buffer overflows and/or off-by-one errors. Programmers are.
The current setup leads to a number of core applications getting a lot of scrutiny from black and white hats, and in consequently having quite lower than industry standard bug density. A certain ratio of the few remaining bugs in system facilities can be amplified into an exploit for taking over the system.
The HURD architecture is a game changer in that area. Whether it or its concepts will ever take flight depends on how much people are willing to change the game. The current game is pretty well-explored, and long-term investments and employments have been based on its dynamics.
First of all, nobody uses ring 1 and 2. Secondly, do you still run dos that you only have a single application running?
OS X is a microkernel.and appears to be doing quite well.
OSX does not have a microkernel.
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.
While you're correct that Windows implements too much of its GUI in kernel mode, it is not true that a good chunk of that code shouldn't be there.
For ages, X11 has been essentially user mode only, directly playing with hardware from userspace. Not a good thing.
With the implementation of kernel-modesetting, the really security sensitive parts of the code are now in the kernel where they belong, and the user mode parts can only interact with the hardware thru safe, well defined means.
Can't anyone do (micro)kernel in ring 0, user services in ring 1, VM hypervisors in ring 2 and VMs in ring 3?
Mach != microkernel. It's a piece of operating system building block code which implements virtual memory primitives, task context switching, and IPC primitives (message passing).
Now, one obvious (and common) thing to do with those three basic pieces of functionality is to use Mach as a microkernel in a true microkernel OS, one where device drivers and filesystems and so forth are farmed out to separate tasks which live in independent virtual address spaces and communicate with each other via Mach IPC. Paring the highest privilege code down to VM, process management, and IPC primitives, and implementing the rest as isolated message passing modules -- that's pretty much the classic definition of a microkernel.
But you don't have to use Mach that way, and the OS X "Darwin" kernel doesn't. Everything in-kernel lives in a single address space, and communicates by direct function calls instead of message passing. Some userland features (shared mem, IPC, threads) are built on top of Mach primitives instead of the traditional BSD primitives, but that doesn't make the kernel a microkernel, just a funny BSD variant with Mach code replacing a bunch of the BSD code.
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.