from the we're-gonna-create-our-own-mistakez! dept.
There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems. It's called Redox OS and is available on GitHub. It's aimed at creating an alternative OS that is able to run almost all Linux executables with only minimal modifications. It features a pure ecosystem using the Rust programming language which they hope will improve correctness and security over other OSes. They are not afraid to prioritize correctness over compatibility. The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."
Redox levels harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
Redox OS seems to be supported on the i386 and x86_64 platforms. The aims are microkernel design, implementation in Rust language, optional GUI — Orbital, newlib for C programs, MIT license, drivers in userspace, common Unix commands included, and plans for ZFS.
They want to do away with syscalls that stay around forever and drivers for hardware that, for a long time, simply isn't possible to buy any more. They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system? One aspect to look out for is if they map the graphic cards into user space.
Related Stories
Redox OS (the Unix-like microkernel OS written in Rust) is working on a native Coreboot payload along with bug fixes and a new release.
Lead Redox OS developer Jeremy Soller tweeted that "it's time for Redox OS to become a Coreboot payload." It looks like Redox OS is working on native Coreboot payload support for this interesting Rust operating system rather than first needing to use one of the bootloaders as a Coreboot payload before hitting Redox OS.
[...] The Redox OS twitter also went on to outline they are working on fixes to their networking stack, fixes to curl / cargo / git, advancing towards the state of being able to self-host itself (build Redox OS on Redox OS), improving the relibc C library implementation, porting more applications to running on Redox OS, and at that point to also prepare a new release. And, yes, exploring Coreboot payload capabilities.
Previously: Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
Version 0.5 of Redox OS was released yesterday, which includes a new C library written in Rust and images based on new bootloaders for both coreboot and EFI.
It's taken a while since the previous release of Redox OS as they have been focusing their attention on Relibc, a C library implementation written within the Rust programming language. Relibc is now used as the operating system's default C library.
Redox OS 0.5 also includes improvements to its event system, Pthreads support was completed, better support for LLVM and LLVM-using projects like Mesa/LLVMpipe, improvements to EFI, and more.
Some new Rust-written packages for Redox OS include OpenGL wrappers, an audio library, and other additions. Outside of the Rust scope, Redox OS 0.5 adds in SDL2 packages, Cairo, FFmpeg, and many other important software options.
You can find the Redox OS 0.5 release notes here, and can find the 0.5.0 images here.
Previously: Redox OS Exploring Coreboot Payload
Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
The ISRG wants to make the Linux kernel memory-safe with Rust
The Internet Security Research Group (ISRG)—parent organization of the better-known Let's Encrypt project—has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis.
As we covered in March, Rust is a low-level programming language offering most of the flexibility and performance of C—the language used for kernels in Unix and Unix-like operating systems since the 1970s—in a safer way.
Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts—not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly.
Using Rust for new code in the kernel—which might mean new hardware drivers or even replacement of GNU Coreutils—potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows—significant sources of performance and security issues in complex C-language code.
Previously: Linus Torvalds: Don't Hide Rust in Linux Kernel; Death to AVX-512
Related: Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
Following Layoffs, Mozilla and Core Rust Developers Are Forming a Rust Foundation
(Score: 5, Insightful) by Anonymous Coward on Tuesday March 22 2016, @08:37AM
> ...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on.
As if anyone ever set out to replicate the mistakes of the past.
They sound like they are about 15 years old and know everything.
(Score: 1, Insightful) by Anonymous Coward on Tuesday March 22 2016, @10:52AM
My thoughts exactly. Already I don't want to associate myself with a project that has a community with that sort of attitude.
By doing so, they are making mistakes the other operating systems developers did not.
(Score: 3, Touché) by RedBear on Tuesday March 22 2016, @11:32AM
Heh. I can see the press release from about 25 years from now: "FyutrOS will not replicate the mistakes and bad choices made by Linux, Unix, BSD, HURD, Redox OS and so on..."
¯\_ʕ◔.◔ʔ_/¯ LOL. I dunno. I'm just a bear.
... Peace out. Got bear stuff to do. 彡ʕ⌐■.■ʔ
(Score: -1, Redundant) by Anonymous Coward on Tuesday March 22 2016, @12:20PM
If you follow the standard you have external limits on quality. If you dont follow the standard you might be failing to learn the lessons of the past.
They sound like they are about 15 years old and know everything.
So do you.
(Score: 1, Redundant) by DannyB on Tuesday March 22 2016, @02:08PM
Maybe they sound more adult than you think.
They merely state, quite correctly, that there ARE design mistakes of the past. (And no past system, no matter how elegant, that I have ever seen since the 1970's is free of design mistakes that couldn't have been done better in hindsight.)
They do not intend to repeat those mistakes. I read 'repeat' to mean 're-implement' those mistakes.
While unstated, they probably will also invent some new design mistakes. Hopefully few. And hopefully not serious. Even better if they are easily corrected.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1, Interesting) by Anonymous Coward on Tuesday March 22 2016, @05:04PM
Compatibility means deliberately repeating other people's mistakes.
— David Wheeler
[...] able to run almost all Linux executables [...]
(Score: 3, Insightful) by Nuke on Tuesday March 22 2016, @10:48PM
They want to do away with .... drivers for hardware that, for a long time, simply isn't possible to buy any more.
There's a design mistake for a start.
Just because some hardware cannot be bought any more does not mean that it is not still in widespread use. My IBM Model M keyboard with its PS/2 connector for example? No thanks, I'll pass on Redox.
(Score: 2) by darkfeline on Wednesday March 23 2016, @01:38AM
They're replicating the mistakes of, e.g., Minix, for one.
Either you can make something perfect, or you can ship a product. Choose one.
Join the SDF Public Access UNIX System today!
(Score: 5, Insightful) by multixrulz on Tuesday March 22 2016, @08:42AM
... they don't know the first thing. They're using a github SSL certificate on redox-os.org.
But more to the point, get back to me when it's as functional as ReactOS.
(Score: 1) by Cornwallis on Tuesday March 22 2016, @09:20AM
You beat me to it. Way to inspire trust right out the gate.
(Score: 2) by tangomargarine on Tuesday March 22 2016, @01:58PM
Wow, a *red* untrusted connection page. I can't even remember the last time I've seen one of those.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Nuke on Thursday March 24 2016, @11:29AM
Wow, a *red* untrusted connection page [www.redox-os.org]
Indeed. And they are complaining about "design mistakes"!
(Score: 2, Funny) by Anonymous Coward on Tuesday March 22 2016, @09:10AM
i see their first fuck up; using github
they should be using bitbucket!
grab pitchforks!
(Score: 3, Insightful) by ThePhilips on Tuesday March 22 2016, @09:11AM
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system?
But this is just perspective of developers, who are ridiculous minority compared to users of the kernels.
From perspective of users, it makes no sense to make more checks/etc during run-time, since the code doesn't change during run-time. After the systems has been tested, the checks/etc are pure and useless overhead. (Microkernel's isolation features are also sort of checks for invalid memory accesses.)
Or as a direct example: Would you as a gamer play a game which never crashes at 25fps, or rather a game which might/might not crash once per week at 50fps? And that's pretty much sums up why the "better" microkernels never took off: it's not developers with their unsafe languages/etc, it is the users.
One aspect to look out for is if they map the graphic cards into user space.
As soon as you allow unfettered access to IO registers from user-space, all the security promises fly out of windows. And you can't have a driver in user-space without unfettered access to IO registers.
(Score: 3, Informative) by mth on Tuesday March 22 2016, @09:47AM
In modern Linux, graphics drivers have a large user space part that builds command buffers and a small kernel driver that verifies command buffers and sends them to the hardware. I think that's about as good as it's going to get with current PC hardware. If a system has an IOMMU, perhaps more could be moved to user space. I read something about AMD putting IOMMUs in their APUs, but I don't know if that's already present or something on their roadmap.
(Score: 3, Insightful) by VLM on Tuesday March 22 2016, @11:46AM
since the code doesn't change during run-time
Um, that would be nice. Usually true, other than when someone is breaking in.
(Score: 2) by ThePhilips on Tuesday March 22 2016, @12:09PM
The NX bit [wikipedia.org] takes care of that for some time now. It allows to make the memory either writable or executable, but not both.
But past all the HW and SW protection mechanisms come the logical errors. And the logical errors are independent of the language. If hacker can convince application to delete all data, or overwrite it with junk, no amount of abstract safety features would help.
Otherwise, as a system developer, I do not mind - in fact, I welcome - such experiments. An advent of another system programming language beside C could only be a positive news. But I do not have much expectations toward the OS rewrite. If they were really serious about Rust as system language, as first step they should have tried integrate the support with BSD or Linux kernels, to allow writing drivers completely in Rust. But since they have started from the wrong end - rewrite of an OS - I really do not have any kind of hopes of them succeeding.
(Score: 2) by Pino P on Tuesday March 22 2016, @03:16PM
The NX bit does not defend against return-oriented programming.
(Score: 0) by Anonymous Coward on Tuesday March 22 2016, @05:55PM
I haven't been keeping up lately and hadn't heard about that technique [wikipedia.org]. That's quite a fancy way to smash the stack!
(Score: 3, Informative) by TheRaven on Tuesday March 22 2016, @01:45PM
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system?
Whoever wrote this has no credibility. There is no mathematically proven L4 kernel. There is seL4, which is a formally verified microkernel that is inspired by L4 (but not an L4 implementation). It was a whole 8 hours between the public release of seL4 and the first security hole being identified, because it was something that wasn't part of their formal specification (which also makes a number of assumptions about the MMU behaviour that are not always true given known hardware bugs).
The authors of seL4 put the cost at around 30 times that of developing with state-of-the-art informal software development methodology (i.e. detailed design, comprehensive test suites, and so on).
As soon as you allow unfettered access to IO registers from user-space, all the security promises fly out of windows. And you can't have a driver in user-space without unfettered access to IO registers.
What you say is true, assuming that you want to run on old hardware. If you are running on anything even vaguely modern, then as long as you correctly set up the IOMMU then this is not a problem. It's worth noting (to give a concrete example) that nVidia drivers have had direct access to I/O registers from userspace for several generations of hardware - all that the kernel part of the driver does is set up the initial mapping of the control registers and map and unmap memory segments. Nothing on the fast path for typical operation involves the kernel at all.
sudo mod me up
(Score: 2) by ThePhilips on Tuesday March 22 2016, @02:02PM
What you say is true, assuming that you want to run on old hardware.
Any DMA-capable piece of hardware (today it is pretty much every piece of hardware) can be used to bypass completely any security mechanism, because it, duh, allows to access RAM directly without involvement of the CPU.
I had already experience of (inadvertently) sending my stack over the network. And receiving the network packets into the stack.
nVidia drivers have had direct access to I/O registers from userspace for several generations of hardware
Not really. All "dangerous" commands are still has to be done via kernel part. They have access only to the IO-mmaped registers relevant to the graphical pipeline. User-space can fill the pipe-line of the GPU with data and commands, without calling the kernel, but flushing/syncing/etc (as well as configuration) is still done via kernel. IIRC, at least once per frame they have to call the kernel.
(Score: 5, Informative) by TheRaven on Tuesday March 22 2016, @02:22PM
Any DMA-capable piece of hardware (today it is pretty much every piece of hardware) can be used to bypass completely any security mechanism, because it, duh, allows to access RAM directly without involvement of the CPU.
No, it accesses RAM via the IOMMU (if one exists, which it does on all modern hardware - even without a full IOMMU [which does translation as well as protection], AMD CPUs have had a device exclusion vector for a decade, which allows the host CPU to restrict the physical pages that a device may access). The device can only access memory if there are valid mappings from the device virtual address space to the physical address space[1].
The IOMMU does the same thing for the device that the CPU's MMU does for unprivileged code: it performs translation and permission checks on each virtual address and prevents unauthorised reads and writes.
Note that many modern operating systems either misconfigure or don't bother to configure the IOMMU. Ubuntu is particularly fun, as it will advertise that the IOMMU is configured, even when it isn't.
Not really. All "dangerous" commands are still has to be done via kernel part. They have access only to the IO-mmaped registers relevant to the graphical pipeline. User-space can fill the pipe-line of the GPU with data and commands, without calling the kernel, but flushing/syncing/etc (as well as configuration) is still done via kernel. IIRC, at least once per frame they have to call the kernel.
This is simply not true (and please, go and read the driver code if you don't believe me - I'm speaking from first-hand experience here). Flushing the command buffer is done by writing to the producer (memory mapped device I/O) register from userspace. Userspace can poll for space in the ring buffer by reading another memory-mapped register.
Graphics cards aren't the only devices to prefer this mode of operation. Infiniband devices have supported it forever and recent(ish) high-end NICs all support a kernel-bypass mode, where the device provides a virtual instance via SR-IOV that can all be mapped directly to userspace processes (or guest VMs). This is needed if you want to move the device driver entirely into the userspace process that's using it (increasingly common these days), but for a microkernel to grant direct access to a single driver process you just need an IOMMU. This isn't even a topic of research - several microkernels do this already.
[1] Note that PCIe has some odd modes, such as permitting a device to indicate that it has a pre-translated physical address. This can be disabled, but the host OS must remember to do so.
sudo mod me up
(Score: 2) by ThePhilips on Tuesday March 22 2016, @02:42PM
The IOMMU does the same thing for the device that the CPU's MMU does for unprivileged code: it performs translation and permission checks on each virtual address and prevents unauthorised reads and writes.
That's interesting.
But "virtual address" you are talking about? The DMA works *always* on physical RAM. Or is it different kind of "virtual" memory?
All the CPU memory protections I have seen work in concert with and rely on virtual memory. The "virtual memory address space" is process-specific - external hardware doesn't know anything about it.
And how is this IOMMU is going to protect anything, when
(1) the mapping virtual-to-physical is 1:1, while the same physical memory can have multiple virtual addresses (for different processes; consequently with different permissions) and
(2) a very basic system can have rather huge number of virtual mappings, and no hardware ever is going to be as flexible as to allow unlimited number of the configuration entities (or it would have to go to the RAM for the configuration, and suffer the same performance penalty as the virtual memory machinery).
In the Linux kernel, in the API for the DMA memory I've seen in the traces that it can potentially do something special for the memory, but so far I haven't worked with a single arch which implements there something (I worked only with PPC, ARM and Intel). Out of interest I have looked deeper, but only found handling for architectures which have limitations that not all memory is DAM-able. But nothing anywhere close to the protection against a malicious DMA access. (The same limitation was applicable to the older ISA hardware on Intel architectures, which could only access with DMA the first megabyte of the RAM.)
(Score: 3, Informative) by TheRaven on Tuesday March 22 2016, @05:00PM
But "virtual address" you are talking about? The DMA works *always* on physical RAM
No it doesn't. It only works on physical memory in the absence of an IOMMU. With an IOMMU, it works on a device virtual address.
And how is this IOMMU is going to protect anything, when (1) the mapping virtual-to-physical is 1:1, while the same physical memory can have multiple virtual addresses (for different processes; consequently with different permissions) and
Virtual to physical mapping isn't 1:1, it's N:1. That's how shared memory works - multiple virtual page corresponding to the same physical page.
In the Linux kernel, in the API for the DMA memory I've seen in the traces that it can potentially do something special for the memory, but so far I haven't worked with a single arch which implements there something (I worked only with PPC, ARM and Intel).
Most of the Linux APIs were introduced for PowerPC (contributed by IBM over a decade ago), so if you've worked on PowerPC then I'm quite surprised that you haven't come across them. They're used to prevent device driver errors affecting other parts of the system on IBM hardware. They're also used for device pass-through in virtualisation environments.
Just looked for Intel/AMD IOMMU specs and they are all files under "Virtualization" and "I/O Virtualization"
Of course they are, just as memory protection is under 'virtual memory'. What do you think virtualisation means?
IOW, the tech is not intended to be used by the host - but rather to implement IO for the guest OS. In that case, the "virtual address" makes sense: it is the physical address of the guest OS, but the virtual memory address of the VM software.
You're confusing marketing with functionality. You're also completely missing the common uses. Kernel bypass is most commonly used in graphics cards and high-end network cards, without a hypervisor (though hypervisors do use the same mechanisms for device pass through). As I said, nVidia cards for the last few generations have all supported kernel bypass. The kernel sets up memory maps, but all commands are submitted directly from userspace to the card without the kernel being involved. The kernel simply sets up mappings for memory that both the process and the device can access. High-end network cards work in the same way (Infiniband has worked like this for 20+ years), with the kernel setting up memory maps and the userspace drive initiating DMA to and from the rings that are in memory shared between the device and the userspace process.
If you don't want to believe me, then go and read the driver code. Or read the reverse-engineered docs for the nVidia cards from the Nouveau project.
sudo mod me up
(Score: 2) by RamiK on Wednesday March 23 2016, @01:04AM
Most of the Linux APIs were introduced for PowerPC
He might have worked on Macs or PowerQUICC. Not all PPCs were\are at feature parity. Especially when it comes to virtualization* which, similarly to ECC memory, was sometimes offered as a server "premium" feature.
As for seL4, many production L4 family kernels fork off the proven seL4 code base and add patches to address hardware bugs. It's not a "security hole" to have a proven and correct core serve as a main branch that you occasionally fork production branches off and patch for hardware specific issues. It's simply a different development model.
As for RedoxOS, while I personally believe it's a waste of time seriously developing anything new targeting the x86's metal, Rust still needs to prove itself by at least developing it's own toy research operating system. It's the price you pay for calling yourself a systems programming language. D is in the same boat. Go had the sense to avoid it.
*virtualization is the modern term for general memory\device protections, like you said.
compiling...
(Score: 2) by ThePhilips on Tuesday March 22 2016, @02:47PM
Just looked for Intel/AMD IOMMU specs and they are all files under "Virtualization" and "I/O Virtualization". IOW, the tech is not intended to be used by the host - but rather to implement IO for the guest OS. In that case, the "virtual address" makes sense: it is the physical address of the guest OS, but the virtual memory address of the VM software.
(Score: 0) by Anonymous Coward on Tuesday March 22 2016, @10:10AM
do away with the old mistakes and cruft in other operating systems [...] able to run almost all Linux executables
Good luck with that pipe dream.
Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
More like it contains a placeholder for a blunt critique of Plan 9 and the GPL.
Everything is a URL? [redox-os.org] What a joke.
I'll stick with Urbit for all my meme operating system needs, thank you very much.
(Score: -1, Redundant) by Anonymous Coward on Tuesday March 22 2016, @12:11PM
We don't want another Win10 though.
(Score: 5, Insightful) by tangomargarine on Tuesday March 22 2016, @01:44PM
There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems.
"Those who do not learn from UNIX are doomed to reimplement it, poorly."
The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."
obligatory xkcd Standards [xkcd.com]
In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
"We know better than all these knuckleheads with their system that's actually been working for the last few decades."
The aims are microkernel design, implementation in Rust language,
Hey look, hipsters using Rust.
drivers in userspace
These guys have heard of HURD, right? Although I suppose that's kind of the platonic ideal of project failure and that doesn't necessarily mean these guys will, too.
They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.
Fast-forward 10 years. Hey, look! Now they're 25 million lines of code, too! Oops.
I know I'm still a wet-behind-the-ears software dev, especially concerning OSes, but I still know enough not to throw everything out the window and think I can rewrite it all myself, better.
Somebody needs to set up a cage match between these guys and Lennart Poettering :)
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 5, Insightful) by LoRdTAW on Tuesday March 22 2016, @01:53PM
You want to be taken seriously? Remove the endless bitching and critique. Most people interested in new OS designs are well aware of the existing crap designs (hint: they all suck save for Plan9/inferno). Their manifesto reads like the pipe dream of a bunch of know-it-all kids.
This is more akin to a bunch of guys in a bar, drunk, and boasting of plans to climb mt. Everest. They all agree that they want to do it, but once they realize the scale of the journey, they abandon it. I don't exactly have high hopes. Writing a completely new OS takes an enormous amount of passion and drive.
(Score: 0) by Anonymous Coward on Tuesday March 22 2016, @04:57PM
(hint: they all suck)
ftfy
plan 9 is better than most operating systems, but like all software, it sucks
also rob pike can't into user interfaces
seriously rob what the hell are you doing, stop it
(Score: 2) by LoRdTAW on Tuesday March 22 2016, @05:23PM
A cat-v reader I see. But in all seriousness, it does suck from a user standpoint as well. However, the underlying architecture is clean and lightweight while 9p and the VFS enable an amazing level of distribution of resources. It doesn't get better than that.
So you're saying he accidentally the user interface then.
(Score: 2) by Pino P on Tuesday March 22 2016, @03:18PM
The certificate presented by the web server that handles https://www.redox-os.org/ [redox-os.org] works only for www.github.com, *.github.com, github.com, *.github.io, github.io, *.githubusercontent.com, and githubusercontent.com, not www.redox-os.org.
(Score: 2) by Subsentient on Tuesday March 22 2016, @07:49PM
Looks like Hipster OS (tm).
Let me guess, they'll implement the GUI in pure Javascript and take design ideas from systemd.
Rust? Really? I mean, it's not a bad language as far as I can tell, but it's not particularly portable yet, at least not to the extent of C/C++.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti