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."

Comments

Re:Does it run Beta?

[Jeremiah Cornelius]

User Space Drivers != "Improvement".

This is normally called a "defect". Performance design failure and security disaster, in one convenient package!

HURD is an embarrassment

[realmolo]

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.

Re:HURD is an embarrassment

[serviscope_minor]

Having a project like HURD reflects poorly on Open Source/Free software.

Rubbish. It's a hobby/research project for a few people at the moment. This no more reflects poorly on Open Source software than my crap github account.

Stallman should just kill it. It's pointless.

Tell you what, I'll petition Stallman to ask them to stop (RMS doean't have to power to tell people what to do in their spare time and I doubt he'd weald it if he did) if you agree to cease all your hobbies since you're not pro-level at any of them.

That aside, it's actally beginning to get to the interesting stage. Things are beginning to work quite well. It's soon going to be able to use all of the Linux drivers (i.e. no hardware support problems). The capabilities are interesting because it can do all of this without hacks or root. This gives a much smaller attack surface.

It's also interesting because the difficult and complex security concious important system code can be written in something other than C very easily. In facy you can cobble together all sorts of stuff in all sorts of languages if desired.

Re:HURD is an embarrassment

[jandrese]

I don't think it reflects badly on FOSS as a whole, it just shows that Stallman doesn't seem to know when he is in over his head, and is too difficult to work with to attract a sizable developer base for support. It is true that Open Source projects need a sensible leader just as much as regular companies do, but that shouldn't be a surprise. I guess there is one problem in FOSS where, especially on non-megahuge projects, when the original leader steps down there is no meta-organization (like some sort of open source CEO) to appoint a new one, and if nobody volunteers a project can flounder and die. I've seen this happen to many projects over the years, even ones I still use despite minimal maintenance for several years.

Notable examples of this include WindowMaker (which did see a new release a couple of months ago, so maybe someone cares again), and Pan, which was by far the best newsreader available to people with powerful machines but died right around the time most ISPs were pulling their free Usenet access.

Re:HURD is an embarrassment

[serviscope_minor]

just shows that Stallman doesn't seem to know when he is in over his head,

Yay. Today is "make shit up about Stallman day" just like every other day.

Let's go for an RMS quote on the HURD:

"finishing it is not crucial" for the GNU system because a free kernel already existed (Linux), and completing Hurd would not address the main remaining problem for a free operating system: device support.

Re:HURD is an embarrassment

[Anonymous Coward]

This no more reflects poorly on Open Source software than my crap github account.

Yeah, we weren't going to bring up your "contributions" quite yet, but since you mentioned it...

Re:HURD is an embarrassment

[DrXym]

But Linux *didn't* exist when Hurd was started. It was the moribund state of development 23 years ago which motivated Linus to write his own kernel. So in a sense we should thank Hurd for being so badly mismanaged, mired in politics and kernel correctness that it drove someone to produce something better and more useful. Pragmatism won the day.

Re:HURD is an embarrassment

[serviscope_minor]

"Your signature project has been in development hell for over 20 years, how do you respond?"

You're making stuff up. Making up things is generally known as lieing. I'll be generous and assume that you're merely staggeringly ignorant and perfer to regurgitate anti-GNU talking points you've culled from various message boards and have never bothered to actually find out much about the GNU project yourself.

The HURD kernel is not and has never been the "signature" project. The project is the GNU project (est. 1983) and has been progressing quite nicely. The kernel was not worked on until about 1990. When Linux came along in '91, it was rapidly adopted as the GNU kernel of choice, since it is under an appropriate license.

The goal is to be able to run computers entirely from copyleft software. The fact that some of these were achieved externally is neither here nor there. The GNU project has in fact achieved its major goal: you can now run a computer on completely copyleft software.

Re:HURD is an embarrassment

[operagost]

His preferred distro is gNewSense, running on his Lemote Yeedong laptop, based on the Loongson CPU.

Ye gods, if I didn't know any better I'd say that was all made up gibberish on the spot. Lemote Yeedong... yeah, that's the ticket.

Re:HURD is an embarrassment

[Pseudonym]

They did play with L4, which is an even better choice.

Re:Does it run Beta?

[Anonymous Coward]

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.

Linux vs. Hurd/xBSD

[jellomizer]

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.

Re:Linux vs. Hurd/xBSD

[Trepidity]

I agree it's basically a confluence of circumstances. Fwiw, while GNU's kernel project was pretty unsuccessful, I do think their more general project of trying to put together all the parts of a free Unix-like was quite useful, and one part of the circumstantial confluence. With BSD tied up in licensing issues at the time, Linus was able to basically grab the GNU compiler, libc, userland, etc. and make a working system. GNU's efforts were less essential to the BSDs after the lawsuit was resolved, but still fairly important in the early years to get something up and running: the lawsuit resolution resulted in ripping out the AT&T-licensed code from BSD, a bunch of which was replaced by GNU utilities as drop-in replacements. These have since been re-replaced in most of the BSDs ('grep' was one of the last GNU utilities to be phased out), but served as a pretty useful 20-year stopgap. And of course GCC had replaced the traditional CC much earlier (GCC appears in 4.3BSD).

One missing bit of this soup that's a real shame, imo: The very late open-sourcing of Plan9 led to a bunch of good stuff that could've been pulled in being ignored. If at least parts of Plan9 had been available in the early '90s when this GNU/BSD/Linux code was coalescing into free operating systems, Plan9's code could've contributed usefully.

Re:Does it run Beta?

[Anonymous Coward]

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.

Re:Micro Kernel, Failed Computer Science Pipe drea

[Dr. Spork]

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.

Re:Can drivers move so easily from kernel to user?

[Unknown Lamer]

There's a Device Driver Environment that emulates parts of Linux as calls to other servers and Mach. Slides 22-25 have a bit of info on the port from running inside Mach to userspace.

Re:Does it run Beta?

[Jeremiah Cornelius]

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!

Comment removed

[account_deleted]

Comment removed based on user account deletion

GNU HURD

[Chas]

Bringing you the technology of 1997...TODAY!

Re:Micro Kernel, Failed Computer Science Pipe drea

[Trepidity]

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.

Re:Does it run Beta?

[Anonymous Coward]

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)"

GNU Hurd: A Solution In Search of a Problem

[sirwired]

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.)

That's nice...

[SplawnDarts]

User space driver's are one thing, but I'm still waiting for the day whe HURD gets a user.

Re:Micro Kernel, Failed Computer Science Pipe drea

[LoRdTAW]

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):

Performance is therefore a potential issue in microkernel systems. Indeed, the experience of first-generation microkernels such as Mach and ChorusOS showed that systems based on them performed very poorly. However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive page cache footprint. Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. L4's IPC performance is still unbeaten across a range of architectures.

While these results demonstrate that the poor performance of systems based on first-generation microkernels is not representative for second-generation kernels such as L4, this constitutes no proof that microkernel-based systems can be built with good performance. It has been shown that a monolithic Linux server ported to L4 exhibits only a few percent overhead over native Linux.[15] However, such a single-server system exhibits few, if any, of the advantages microkernels are supposed to provide by structuring operating system functionality into separate servers.

A number of commercial multi-server systems exist, in particular the real-time systems QNX and Integrity. No comprehensive comparison of performance relative to monolithic systems has been published for those multiserver systems. Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize reliably quick interrupt handling response times (QNX) and simplicity for the sake of robustness. An attempt to build a high-performance multiserver operating system was the IBM Sawmill Linux project.[16] However, this project was never completed.

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.

Re:Micro Kernel, Failed Computer Science Pipe drea

[amorsen]

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.

Re:Does it run Beta?

[smash]

NT itself is designed pretty well. It's the Win32 layer which is garbage.