Genode OS 13.02 Features Low Latency Audio, Virtualization, Protected DMA

← Back to Stories (view on slashdot.org)

Genode OS 13.02 Features Low Latency Audio, Virtualization, Protected DMA

Posted by Unknown on Thursday February 28, 2013 @06:50AM from the dreaming-of-hurd dept.

On the heels of their December release, the 13.02 release of the Genode multi-server microkernel OS framework continues to deliver major new features. Under the hood, there's support for the IOMMU, bringing safe bus master DMA to userspace drivers (overcoming one of the final advantages monolithic kernels had). They've also added full virtualization support, good enough to boot Linux as an application. In the cool department, they've added a new low latency audio interface that could very well pave the way for something akin to JACK, and right now provides a lightweight way for the system to beep at you in real time . A few more libraries have been ported (libssh, curl, iconv) in preparation for a port of git to the Noux native GNU runtime. There are also a bunch of other improvements to their NOVA microkernel, support for running on the Exynos 5250 and Freescale i.MX53, a new console multiplexer, improvements to the display server, simplification of the base libraries, and more. I'll be attempting to build it and give it a spin to see how well it works in practice sometime soon.

41 comments

Min score:

Reason:

Sort:

It's a HURG by TechyImmigrant · 2013-02-28 06:54 · Score: 3, Funny

HURG: Hurg of Unix Replacing Genodes

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
No, thanks by marcello_dl · 2013-02-28 07:04 · Score: 2

No, I rather keep a monolithic kernel for performance. Then I'll enable some security hooks... and run server and sensitive stuff in a VM... hoping that the bare metal which I use for games won't get compromised... hmm...
OK, TANENBAUM WAS RIGHT.

--
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
1. Re:No, thanks by bluefoxlucid · 2013-02-28 08:44 · Score: 2
  
  Actually tanenbaum WAS right.
  Minix displays roughly a 4% slowdown at worst, which isn't really a lot. It's considerable that 18% of code should probably run in kernel. Application code doesn't experience such a slow-down. 4% of 18% is about 0.72% total. This is pathetically little, so much so that even if you hit it with a fully loaded Web server you're talking about a situation that would kill your server anyway (consider: as soon as you dip a few connections for 3-5 seconds, your system catches up to the past hour or so of max load... 100% workload that takes 1 hour takes 35 seconds longer, so the moment you'd normally back off 100% CPU you have the headroom to blast that away OR you're running a non-stop square block maxed at 100%, so you're dead anyway).
  On the other hand, this Genode thing is another L4-Linux-alike. Can't write a microkernel like Minix? Write a glorified hypervisor and load Linux on top of it as a guest OS, and call it a "Microkernel Architecture." You get all the advantages of being slower, with none of the disadvantages of having a better, decoupled architecture and without a refined and stable product like VMware or KVM or Xen and management tools like vSphere or oVirt. Great press release.
  
  --
  Support my political activism on Patreon.
2. Re:No, thanks by Yebyen · 2013-02-28 09:00 · Score: 2
  
  Whoa there! Have you actually tried Genode?
  Maybe you have, but I think that just because you can run Linux on it does not mean you must.
  I mean, sure, there's no built-in support for filesystems on block devices. I was kind of expecting to see that in the next release. But who needs read-write filesystems anyway? ^_^
  I don't follow you, just because Linux can run on L4, and Linux can run on Genode, and Genode can run on L4,
  Besides that... "another" L4Linux-alike? Where do you find them all? What news outlets do you frequent? Because I honestly haven't heard of dozens of projects just like Genode. This is not an attempt at flaming. You're obviously not convinced that you need a Genode, and clearly neither am I. I'll be the first to admit it's hard to have a thought-provoking discussion about something you don't know exactly what it does, and you're not sure why you need it.
  I was particularly disappointed when after hours of fiddling around just to bring up something called Noux that was finally resembling a shell, I was able to bring it down (and it seemed, the whole Genode system with it) just by typing 'ls'. Maybe that's just not how it's meant to be used. Maybe I just didn't know the correct recovery sequence. I was impressed but just more-so impatient. Glad to know that these guys make new releases every 3 months.
  
  --
  Restating the obvious since nineteen aught five.
3. Re:No, thanks by Anonymous Coward · 2013-02-28 09:16 · Score: 0
  
  Actually tanenbaum WAS right.
  Minix displays roughly a 4% slowdown at worst, which isn't really a lot. It's considerable that 18% of code should probably run in kernel. Application code doesn't experience such a slow-down. 4% of 18% is about 0.72% total. This is pathetically little, so much so that even if you hit it with a fully loaded Web server you're talking about a situation that would kill your server anyway (consider: as soon as you dip a few connections for 3-5 seconds, your system catches up to the past hour or so of max load... 100% workload that takes 1 hour takes 35 seconds longer, so the moment you'd normally back off 100% CPU you have the headroom to blast that away OR you're running a non-stop square block maxed at 100%, so you're dead anyway).
  On the other hand, this Genode thing is another L4-Linux-alike. Can't write a microkernel like Minix? Write a glorified hypervisor and load Linux on top of it as a guest OS, and call it a "Microkernel Architecture." You get all the advantages of being slower, with none of the disadvantages of having a better, decoupled architecture and without a refined and stable product like VMware or KVM or Xen and management tools like vSphere or oVirt. Great press release.
  You have no Idea what you are talking about. Genode is a userland that can run on various microkernels/hypervisor and also on the linux kernel. L4Linux is a feature that you can use on Genode while running the Fiasco.OC microkernel. There are various use cases for virtualized complete operating system on an operating system that is under development. However, L4Linux is not a requirement. If you do not want L4Linux, then do not build it. You still get genode with all the advantages that it offers.
4. Re:No, thanks by bluefoxlucid · 2013-03-01 01:44 · Score: 1
  
  There are a lot of "Microkernels" that amount to a core kernel and then "Linux runs on top of this because it's completely inadequate!" There are things like VMware ESXi that claim to be nothing more than a hypervisor; there are then all these microkernels that claim to be full-feature microkernels, but "are in development" and "have limitations" and "haven't been taken to their full potential" so they run a Linux kernel as a micorkernel service--they virtualize Linux and claim that you're running a microkernel OS, when all you're running is a monolith in a hypervisor.
  
  --
  Support my political activism on Patreon.
5. Re:No, thanks by Anonymous Coward · 2013-03-04 13:05 · Score: 0
  
  > Actually tanenbaum WAS right.
  Yep. The proof is that the Linux kernel is constantly being revised. New versions come out every few weeks or months.
  Shouldn't the kernel be pretty much stable for years? It should really only need tweaking for bug fixes or when some weird new hardware comes out. The incremental changes belong in the drivers and modules.
  (captcha: immature)
Re:GENOCIDE? by BryanL · 2013-02-28 07:17 · Score: 1

I think Genocide is only what happens when the OS crashes. I would like to see the OS up-times before trying this out.
neat by spiffmastercow · 2013-02-28 07:20 · Score: 1

Looks very cool, but what exactly is their business model? It looks to me like this

Step 1: build a cool microkernel
Step 2: Port GNU tools
Step 3: ???
Step 4: Profit!
1. Re:neat by CoolHnd30 · 2013-02-28 07:23 · Score: 1
  
  Looks very cool, but what exactly is their business model? It looks to me like this Step 1: build a cool microkernel Step 2: Port GNU tools Step 3: ??? Step 4: Profit!
  What was Linux's business model?
2. Re:neat by Unknown+Lamer · 2013-02-28 07:23 · Score: 3, Interesting
  
  I think there's a lot of interest in microkernels right now in the mobile world... single chip, running something like OKL4 or Genode with GNU/Linux as a server and the radio stack as another server, completely isolated. It's easier to trust a small microkernel won't allow resources to leak between servers than it is to trust something huge like Xen.
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
3. Re:neat by Anonymous Coward · 2013-02-28 07:31 · Score: 1
  
  Exactly.
4. Re:neat by Anonymous Coward · 2013-02-28 07:35 · Score: 0
  
  What was Linux's business model?
  Step 1: Do it "Just for Fun".
  Step 2: Release under the GPL.
  Step 3: Wait...
  Step 4: I am your GOD.
  Step 5: Profit.
5. Re:neat by spiffmastercow · 2013-02-28 07:55 · Score: 1
  
  Looks very cool, but what exactly is their business model? It looks to me like this Step 1: build a cool microkernel Step 2: Port GNU tools Step 3: ??? Step 4: Profit!
  What was Linux's business model?
  Graduate student thesis?
The Question on Everyone's Mind: by CanHasDIY · 2013-02-28 07:35 · Score: 2

Will it blend?
(wonder how many entendre we can generate with that one...)

--
An enigma, wrapped in a riddle, shrouded in bacon and cheese
1. Re:The Question on Everyone's Mind: by Anonymous Coward · 2013-02-28 08:11 · Score: 5, Funny
  
  They haven't ported Blender's dependencies yet, so, no, it will not blend.
2. Re:The Question on Everyone's Mind: by Medievalist · 2013-02-28 08:39 · Score: 2
  
  Will it blend?
  They haven't ported Blender's dependencies yet, so, no, it will not blend.
  Best post on slashdot in years.
How does it compare to Qubes? by elucido · 2013-02-28 07:36 · Score: 2

It looks like it is on the spot with virtualization but has anyone audited or inspected the code? Are any of these features comparable to Qubes? Why would I choose this OS?
Just asking anyone more familiar with this project to explain to me the pros and cons compared to other projects.
Interesting. Not clear if it's good yet. by Animats · 2013-02-28 07:39 · Score: 2

They're making progress. The system now runs on bare hardware. For a while, it ran on top of Linux, more of a demo than an OS. Now it can run directly on ARM machines. That's useful. It should run on the Allwinner ARM parts from China ($7 each in bulk) and we may see products from China using it.
It's interesting to read over the documentation, what there is of it. The "API reference" is links to C++ .h files which make heavy use of templates. Like this:

typedef Meta::Type_tuple<Rpc_create_thread, Meta::Type_tuple<Rpc_utcb, Meta::Type_tuple<Rpc_kill_thread, Meta::Type_tuple<Rpc_set_pager, Meta::Type_tuple<Rpc_start, Meta::Type_tuple<Rpc_pause, Meta::Type_tuple<Rpc_resume, Meta::Type_tuple<Rpc_cancel_blocking, Meta::Type_tuple<Rpc_set_state, Meta::Type_tuple<Rpc_get_state, Meta::Type_tuple<Rpc_exception_handler, Meta::Type_tuple<Rpc_single_step, Meta::Type_tuple<Rpc_num_cpus, Meta::Type_tuple<Rpc_affinity, Meta::Empty> > > > > > > > > > > > > > > Rpc_functions;

Better for security to do it at compile time than at run time.
1. Re:Interesting. Not clear if it's good yet. by Anonymous Coward · 2013-02-28 08:04 · Score: 0
  
  Jesus that is the most disgusting thing I have ever seen.
2. Re:Interesting. Not clear if it's good yet. by Anonymous Coward · 2013-02-28 08:14 · Score: 0
  
  C++ has no place in operating system kernels. How in the hell is this remotely better than straight up and down c?
  typedef struct Rpc_functions
  {
  Rpc_utcb utcb;
  Rpc_kill_thread kill_thread; ...
  } Rpc_functions;
  Not sure what the types are, but they're probably functor objects that could be replaced with function pointers in the struct kinda like... how linux handles nearly everything under the hood.
3. Re:Interesting. Not clear if it's good yet. by Anonymous Coward · 2013-02-28 08:40 · Score: 1
  
  It's *much* better because of
  1) RAII: If you know how to use the advantages of destructors, your code is *much* more robust than the insane goto arrays typically found in Linux that brought us so many resource leaks and uncountable hours of wasted developer time.
  2) Templating: Give so much nicer abstractions and compile time checks than the crazy casting madness in typical C-programs. Now if only the compilers would produce sane error messages.
4. Re:Interesting. Not clear if it's good yet. by Hizonner · 2013-02-28 08:52 · Score: 2
  
  C++ has no place in operating system kernels.
  True enough. C and all its progeny need to go away. Memory safety and type safety are not optional in critical code.
  Or is that not what you meant?
5. Re:Interesting. Not clear if it's good yet. by Animats · 2013-02-28 08:53 · Score: 2
  
  Some of the strange-looking code comes from using C++ to serialize a sequence of parameters into a byte stream for message passing. The idea, I think, is that you write something that looks like a function call with parameters. Instead of pushing the parameters on the stack for a function call, the compiler turns them into a byte stream and sends them to a message passing interface. That makes sense, although it looks weird.
6. Re:Interesting. Not clear if it's good yet. by advantis · 2013-02-28 11:23 · Score: 1
  
  typedef Meta::Type_tuple<Rpc_create_thread, Meta::Type_tuple<Rpc_utcb, [snip] Meta::Empty> > > > > > > > > > > > > > > Rpc_functions;
  Now that's a _very_ interesting way to build a singly linked list at compile time. And you can append to it at runtime as well. And manipulate it. And all without a writing a single line of linked list management logic yourself and without bringing STL in. Just (ab)using language constructs.
  
  --
  Question for religious people: where do unrepentant masochists go when they die?
7. Re:Interesting. Not clear if it's good yet. by noobermin · 2013-02-28 16:02 · Score: 1
  
  It's funny reading the above C_FOR_LYFE diehard hackers above decrying this. I don't know, this is damn smart, get the language to hard boil a construct. Seriously awesome, although, it is an eyesore.
8. Re:Interesting. Not clear if it's good yet. by drewm1980 · 2013-02-28 21:38 · Score: 1
  
  Amen, brother. But it's a shame that there are basically no mainstream languages that are memory and type safe, but are still suitable for hard real-time use. Ada comes closest. Garbage collection kills most really nice modern languages (like haskell and go) for some applications. C isn't going even have a chance of going away until there is a language that can cover (or at least provide a good low level foundation for) programming for all application domains.
9. Re:Interesting. Not clear if it's good yet. by Anonymous Coward · 2013-02-28 23:04 · Score: 0
  
  Memory safety doesn't make much sense at ring 0/supervisor levels.
Are you writing this up? by Anonymous Coward · 2013-02-28 08:11 · Score: 0

I'll be attempting to build it and give it a spin to see how well it works in practice sometime soon.
Do you have a blog or something where we can follow along? This project looks more than a little interesting.
1. Re:Are you writing this up? by Anonymous Coward · 2013-03-01 16:18 · Score: 0
  
  Because there unfortunately are valid reasons that the links below the title in your parent post could possibly not be helpful enough here are two direct links, first to his homepage:
  http://unknownlamer.org/muse/index.html
  and second to his blog:
  http://journal.unknownlamer.org/
  This Anonymous Coward is just doing what Stephen Fry would have done :) (except without the steaming man sex lol).
Real security... getting closer all the time. by ka9dgx · 2013-02-28 08:37 · Score: 1

I'm glad this project is getting positive attention. It's my main source of hope that computer security will get fixed, for real. I won't miss virus scanners, having to worry about visiting web sites, opening email, etc. When my laptop can run it as a primary OS, I'm switching and never looking back.
Hobbes was right by Anonymous Coward · 2013-02-28 08:46 · Score: 1

"Genode multi-server microkernel OS framework ... IOMMU ... safe bus master DMA to userspace drivers...something akin to JACK... git to the Noux ... NOVA ...Exynos 5250 and Freescale i.MX53." Language is becoming a complete impediment to understanding. At least it beeps at you.
1. Re:Hobbes was right by Anonymous Coward · 2013-02-28 20:27 · Score: 0
  
  hobbes who? oh I should look it up? then maybe you could look up the terms you ignore, too.
2. Re:Hobbes was right by Sigg3.net · 2013-03-01 23:25 · Score: 1
  
  It's the machine that goes BING!
  
  --
  Defining Statistics and Social Research
Use BeFS by Anonymous Coward · 2013-02-28 10:08 · Score: 0

Why not use BeFS? It works. It has several implementations (Haiku, Atheos, & BeOS). It is well documented ("Practical Filesystem Design" by Dominic Giampoalo) It was designed for a similar kind of OS (BeOS). It's not tied to Linux/Unix, but still is (mostly) Posix compliant. Sure, it's not bleading edge, but that would just hold back your project anyhow.
Re:GENOCIDE? by Anonymous Coward · 2013-02-28 11:02 · Score: 0

I WILL use a multi-server microkernel OS framework called GENOCIDE in honor of all the anonymous cowards who died around the world by disregarding warnings of the hazards of Cranial Rectumitis. In spite of faux moral highground, you have to pull your head out of your ass and take an occasional breath.
uKernels and formal proofs... by Anonymous Coward · 2013-02-28 12:51 · Score: 0

The reason why micro-kernels are going to really take off at some point is that program provers are getting better and better.
The "esL4" microkernel L4 variant has been formally proved as immune to a whole lot of common attack vectors. It is known for a fact that you cannot have buffer overflow/overruns, null pointers dereferencing, etc. I don't remember the numbers but while verifying x thousands lines of code, the prover found *hundreds* of potential bugs (and, for many, potentially security issues). All these bugs were indeed bugs and have been fixed. And the prover has been re-run.
The proof itself has been done using a prover that is highly trusted. Nothing is perfect yet but we're slowly getting there. It may take a few more years but in the end the benefit of having a microkernel closing 99.9% (made up on the fly) of all the security holes is going to be a *major* advance.
It's not yet done, but people are working on it.
I personally cannot wait for that day where it is know for a fact that buffer overrun/overflow, pointers dereferencing, etc. cannot be used as attack vectors, no matter how good, how skilled and how rich the attacker.
Simply because it shall be *mathematically provable* that these attack vectors simply aren't there.