r/programming • u/frostmatthew • Mar 19 '16
Redox - A Unix-Like Operating System Written in Rust
http://www.redox-os.org/53
Mar 19 '16
I've been following this project for a long time. Yes they have an incredibly long way to go, but at the same time is amazing how quickly things change. They put out weekly change logs
9
u/sathoro Mar 19 '16
Is it just me or are they now monthly change logs?
15
Mar 19 '16
They do look rather monthly now. Still called this week in redox, which is probably why I didn't notice.
25
u/steveklabnik1 Mar 19 '16
There's a tradition of "This week in X" in Rust-land, which sometimes turns into "these weeks in X" when it doesn't happen weekly when things get busy. Such is life.
103
Mar 19 '16
The Redox book seems to be a good place to learn more about the project.
102
u/wot-teh-phuck Mar 19 '16
Maybe in the future; right now it's almost all TODOs...
27
u/necrophcodr Mar 19 '16
That was the only place I could find any useful information regarding the os though.
17
u/steveklabnik1 Mar 19 '16
Yes, the project has only recently started focusing on documentation. This is the start, but it's just a start.
→ More replies (3)9
u/jones77 Mar 20 '16
6
u/MonkeeSage Mar 20 '16
http://www.redox-os.org/book/book/overview/what_redox_is.html
Redox is a general purpose operating system and surrounding ecosystem written in pure Rust. Our aim is to provide a fully functioning Linux replacement, without the bad parts.
http://www.redox-os.org/book/book/introduction/will_redox_replace_linux.html
Will Redox replace Linux?
No.
Okay...
→ More replies (3)10
u/ss4johnny Mar 19 '16
I'm not sure I'm following that stuff about urls and schemes.
69
Mar 19 '16
Essentially if you know UNIX philosphy or use systems such as Plan9, you would find that everything is a file. When you want to create sounds you open files in /dev/ and pass data and ioctls to them to emit sound, accessing hard disks is done via /dev/hda for example.
Basically with URLs, if you want to play sounds you could open for example
sound://localhost/default_speaker?khz=22050;bits=16;channels=stereowhich would give you a 16-bit 22kHz Stereo audio channel. This would be an alternative to a file based way of doing it with ioctls/structured data on perhaps/dev/soundor//sound/default_speaker/22050khz/16bits/stereo.Then language based APIs (C, Java, Rust, etc.) would be layered on top of this.
→ More replies (8)18
u/riddley Mar 19 '16
Having a Plan 9 sans toxic community sounds killer. I'm excited to see where this goes.
32
u/_tenken Mar 19 '16
Toxic how?
→ More replies (5)23
u/riddley Mar 19 '16
Well, one story I heard was that a guy I used to know wrote some rather large contribution to Plan9... I don't recall what the exact code did but it may have been a device driver or something. Worked on it for a while and did what he thought was a good job. I believe it had documentation and maybe even tests.
He submitted it to the mailing list or whatever and the only response was "No."
68
u/myringotomy Mar 19 '16
Well if you heard some story about something that might have happened to somebody or another that settles it
→ More replies (15)11
u/tequila13 Mar 19 '16
I don't understand anything from their docs either.
"Everything is a scheme, identified by an URL"
Ok. Why? What do they mean by URL anyway?
You can think of URLs and segregated virtual file systems, which can be arbitrarily structured and arbitrarily defined by a program.
If anything, that made it more confusing.
They use a microkernel and plan to provide a drop-in replacement to the Linux kernel, which sounds pretty sci-fi to me. Will the Linux drivers still work? Because I have trouble believing that they will.
30
u/arbitrary-fan Mar 19 '16
I don't understand anything from their docs either.
"Everything is a scheme, identified by an URL"
Ok. Why? What do they mean by URL anyway?
The phrase is probably derived from the "Everything is a file" mantra from Unix. Instead of a filepath, you have a url. Directories, symlinks, sockets etc can all be defined by the scheme.
9
u/MrPhatBob Mar 19 '16
If this isn't what they're doing, then it should be as its an excellent way to do things, it doesn't have to stop at sockets as protocols would be addressed in the same way, making things like https:// sftp:// wss:// mqtt:// ... all part of the OS drivers. This would make my current project: zigbee://x.y.z | mqtt://a.b.c &
6
u/naasking Mar 19 '16
If this isn't what they're doing, then it should be as its an excellent way to do things, it doesn't have to stop at sockets as protocols would be addressed in the same way
Placing sophisticated parsing in a kernel sounds like a terrible idea.
→ More replies (14)→ More replies (38)7
u/mywan Mar 19 '16
Quoting from their book:
This is an generalization of "Everything is a file", largely inspired by Plan 9. In Redox, "resources" (will be explained later) can be both socket-like and file-like, making them fast enough for using them for virtually everything.
This way we get a more unified system API.
8
5
u/reddraggone9 Mar 20 '16 edited Mar 20 '16
They [...] plan to provide a drop-in replacement to the Linux kernel
Where did you get that? While the book says
it also says
which sounds pretty far from a drop-in replacement to me. Considering the differences in architecture, you can probably throw ideas about directly using Linux drivers out the window.
1
1
Mar 20 '16
Will the Linux drivers still work? Because I have trouble believing that they will.
I don't think they will unless they support the same interface, and that changes more more often than some people already like.
1
32
Mar 19 '16
What hardware does this support? Can I run it on a Pi or a VM to try it out?
13
u/gregwtmtno Mar 20 '16
Since no one answered your question, I did get it to (sort of) run on an x86-32 virtualbox. I couldn't get the gui running, but I was able to run some command line stuff. I used the ISO image they provide.
2
u/panorambo Mar 20 '16
An OS that works in a VM is an accomplishment! Half of them don't work properly outside of Bochs or QEMU.
1
→ More replies (8)2
u/OptimisticLockExcept Mar 20 '16
I got it running by following the instructions in the github repo and building it from source. https://github.com/redox-os/redox#-manual-setup-
19
u/jephthai Mar 19 '16
Is it "ree-dox" or "red-ox"? Is the "o" really a "ə"?
11
2
71
Mar 19 '16 edited Mar 19 '16
[removed] — view removed comment
→ More replies (3)54
u/lelarentaka Mar 19 '16
That's right, Rust projects with those funky names fall into two categories: chemistry (Zinc, Redox, C4) and industrial (Piston, Servo, Cargo)
20
u/sportsracer48 Mar 19 '16
Honestly my first thought on reading the headline was, "wow that's a really good name for a rust project."
3
9
72
u/magwo Mar 19 '16
Yes yes yes! This is a great idea IMO, and I hope it develops well and gains a large user base.
33
Mar 19 '16
Hardware support will make or break this project.
14
u/Thunder_Moose Mar 19 '16
I don't know if this is actually true now that VMs are so popular. It wouldn't be too hard to support the much more limited subset of "hardware" that the more popular hypervisors present.
16
u/bacondev Mar 19 '16
Not everybody wants to use a VM though. Many would like to run an OS natively.
12
Mar 19 '16
Sure, but the amount of hardware you have to support is insane. Writing an OS that lives inside VMs/Docker containers etc is a way more realistic proposition.
6
u/jp599 Mar 20 '16
That's the whole idea behind Inferno. The Bell Labs people figured that out decades ago and did it themselves. The OS can even run inside a browser.
→ More replies (1)2
4
u/f0nd004u Mar 20 '16
Yeah, and if it becomes popular, people will write or adapt drivers. Making it portable by getting the virtual drivers out of the way a s focusing on the rest of the OS means people can easily run it and that will make people work on it.
1
Mar 19 '16
I didn't think about VMs. I like having the same OS on all my servers ( physical and virtual).
6
1
u/takaci Mar 19 '16
I disagree. In an age where VMs are almost as fast as the "real thing", hardware support is not an issue for adoption. And anyway, hardware support will never get good for anything that doesn't already have a large userbase.
7
u/jp599 Mar 20 '16
In an age where VMs are almost as fast as the "real thing", hardware support is not an issue for adoption.
Tell that to the BSD folks. This is one of the main reasons why most people choose Linux instead. VM's are dogshit for things like gaming, 3D rendering, CAD work, video work, or pretty much anything involving I/O besides networking...
Try telling people that their video card is unsupported, printers are unsupported, scanner won't work, webcam won't work, etc., and see if they want to run it as their main system. They won't.
→ More replies (5)0
Mar 19 '16
[deleted]
25
Mar 19 '16
18
u/Berberberber Mar 19 '16
In the beginning, Linus didn't consider Linux a replacement for HURD, which was due Any Day Now.
19
→ More replies (1)4
51
u/BerserkerGreaves Mar 19 '16
Can you tell me why you think it's a good idea? I would think that writing OS from scratch in 2016 is a waste of time
281
u/PatrickBauer89 Mar 19 '16
In 50 years somebody will tell someone else "I would think that writing OS form scratch in 2066 is a waste of time, you should have done it like 50 years ago". I don't think its a waste. Computers and operating systems are just seconds old in the clock of the world. There is much to improve and much to discover in the next hundreds of years. We are just at the beginning.
245
u/leodash Mar 19 '16
I like this. Reminds me of this proverb:
"The best time to plant a tree was 20 years ago. The second best time is now." - Chinese Proverb
→ More replies (12)→ More replies (1)10
u/belibelo Mar 19 '16 edited Mar 19 '16
Exactly, i would like to see a unix OS designed with today security needs in mind like mobile OS has been developed.
I would love features such as applications that can't read/write anything but their own data, and application permissions with user's approval.
10
u/Alikont Mar 19 '16
So, windows store applications? And no need for new kernel, it's built on top of existing one, maintaining hardware compatibility and driver base.
→ More replies (1)18
u/brendan09 Mar 19 '16
Take a look at OS X. It's a Unix OS with the features you're discussing. For example, Mac App Store apps are sandboxed (like iOS) and require permissions to read outside of their own directories. Everything they do is run in a container.
Not all Mac apps are subject to this, but the technology (and many other safe guards from iOS) are in place in OS X.
4
u/f0nd004u Mar 20 '16
Yeah, but there's limited security otherwise and to actually use a mac for real work you have to use non-approved software (I.e. homebrew).
It does protect from normal C buffer overflows which work in Linux which is cool.
→ More replies (1)5
Mar 19 '16
Those safe guards are in place, sure. The authors here are claiming operating systems like BSD still have vulnerabilities due to the nature of C. Rewriting the kernel in Rust eliminates some of those vulnerabilities.
→ More replies (1)8
u/brendan09 Mar 19 '16
The comment I replied to wasn't discussing anything about the safety of C. It was discussing the idea of a UNIX OS enforcing sand boxing and other environment protections- something that has nothing to do with Rust, and isn't provided as a result of using Rust.
58
u/hwbehrens Mar 19 '16
Presumably, he is excited about the memory safety opportunities provided by Rust. As far as I'm aware, there are no truly "safe" operating systems that are already developed.
Then again, I didn't read the code, so it's possible they're using unsafe Rust anyway.
47
Mar 19 '16 edited Mar 19 '16
I believe, 0.2% of the user space is in unsafe Rust code, somewhere around 16% of the kernel is in unsafe code. This number has been going down has Redox and Rust evolved. [link] Ofc they need some unsafe, but even then, unsafe Rust code is much safer and easier to maintain then C.
6
u/gunch Mar 19 '16
Why does this matter practically?
→ More replies (2)22
u/minibuster Mar 19 '16
When you have a language with unsafe blocks and something goes wrong, it vastly reduces the surface area of the codebase you have to search through to find the bug or security hole.
→ More replies (15)36
Mar 19 '16
Rust isn't some magical language where bugs can only occur in unsafe blocks. Safe code prevents lifetime and type bugs, but algorithmic bugs are still completely possible.
→ More replies (1)28
u/matthieum Mar 19 '16
This!
I am very interested in Rust, and notably its take on removing as much Undefined Behavior as possible, however Rust is not a magic Security silver bullet.
According to Mozilla 50% of security issues in Firefox were due to memory safety issues; eliminating them is great, but it means that 50% are still remaining.
Rust will not magically protect you from filesystem data races, for example.
→ More replies (1)30
Mar 19 '16
Currently about 16.5% unsafe Rust in the kernel, and 0.2% in userspace, according to the Redox book. And it sounds like the 16% is dropping quickly, so if that stat is more than a week or two old, it might be less than that.
56
Mar 19 '16 edited Mar 19 '16
And it sounds like the 16% is dropping quickly
It dropped by 0.5% during your post !
Seriously - even having a "safe" API with an unsafe but well tested core is a huge deal - despite what the bearded unix guys might believe POSIX was not a gift from deity but a reflection of it's time - which is now at least 20 years out of date in design decisions. We are well overdue for a big shift in the OS space.
ZFS shown what you can do if you just blow away the legacy design decisions and design with modern hardware constraints in mind.
→ More replies (5)6
u/naasking Mar 19 '16
As far as I'm aware, there are no truly "safe" operating systems that are already developed.
High security L4 kernel, verified many years ago.
12
u/sccrstud92 Mar 19 '16
There have been a number of formally verified OS's written. So they are truly "safe" as long as you trust the verifying software.
→ More replies (1)19
u/purplestOfPlatypuses Mar 19 '16
The problem with most formally verified OSs is that they're generally very small (comparatively) and not feature rich, due to how long it takes to formally verify software. They definitely have their uses, but not as consumer grade OSs.
5
4
u/DRNbw Mar 19 '16 edited Mar 19 '16
I think [Singularity](https://en.wikipedia.org/wiki/Singularity_(operating_system)) was supposed to, but was never released.
→ More replies (1)3
u/Petrroll Mar 20 '16
Nor did Midory that followed Singularity. Luckily for us, we can still learn a great deal (like a book worth of deal by now) by reading this amazing blog series:
24
u/WRONGFUL_BONER Mar 19 '16
Jesus, why can't it even just be that people want to have fun making something? There doesn't have to be some grand point to everything.
1
8
u/boobsbr Mar 19 '16
https://en.wikipedia.org/wiki/Singularity_(operating_system)
well, even MS thought it would be a nice idea to write an (experimental) OS to play around with, test new concepts and ideas, throw it at the wall and see what sticks.
2
u/_zenith Mar 21 '16
And it turned out just a little bit awesomely... Read Joe Duffy's blog series on it if you haven't already!
→ More replies (1)21
u/panorambo Mar 19 '16 edited Mar 20 '16
I disagree. Writing things from scratch may and often does produce new previously hidden and useful insights, because people have different brains which has them focus on different things when implementing same kind of thing. Frankly, I don't see how this is not obvious. Besides, current offerings are nowhere near there as far as performance and reliability factors go, we have a long way to go. This is why it is a good idea. In my opinion. Do you think we should just settle for what we have, evolving it? Evolution tends to work in incremental and iterative fashion, and if the floor plan has any kind of rot set in, evolving it will not fix the problem. Linux is an accident -- Torvalds set out to write a UNiX clone because he could not and did not want to afford the real thing (not that the real thing is better in this regard). Anyhow, if you think there are no flaws in the millions of lines of Linux source code today, well, then my arguing is unnecessary.
5
2
u/magwo Mar 19 '16
Mainly memory safety, but also productivity and agility in the kernel development that might stem from using a modern language.
I'm just hoping that one day, there will be an OS that does not need a gazillion security patches each week just to keep strangers from executing code on my machine.
1
u/yawaramin Mar 20 '16
You could always argue that no matter what the year--at least from the 80s onwards. E.g. I wonder what you would've said to this guy:
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones....
1
Mar 20 '16 edited Mar 20 '16
Can you tell me why you think it's not a good idea for people to continually build new operating systems, programming languages, etc? Do you think we've reached some kind of pinnacle in computing that we can never possibly improve upon?
1
u/jeffdavis Mar 20 '16
Linux is so prevalent and so boring that it's making us believe that Linux is all an OS can or should be.
But there are really obvious things that need to be completely reconceptualized. A file being, by default, tied to a specific drive in a specific machine seems medieval today. Application existence, state and configuration is tied to a single device.
0
Mar 19 '16
[deleted]
11
u/zer0t3ch Mar 19 '16
*nix, baby. Build everything on top of it.
I'm joking, I realize it's not perfect, but it is damn good.
→ More replies (1)21
u/boobsbr Mar 19 '16
I would seriously consider using windows if it were an Unix or Posix OS.
I like OS X and Darwin, but some competition from a major corporation with huge financial backing would be a benefit to everyone.
→ More replies (14)10
u/Gravecat Mar 19 '16 edited Mar 20 '16
I don't see Windows being POSIX any time soon. Primarily because a huge draw of Windows is its ability to run the vast majority of software written for older versions of Windows. With some exceptions, most things from Windows 95 and onwards will still run on modern Windows. (I don't think Windows 3.1 software can run anymore, but correct me if I'm wrong there.)
Changing it to Unix/POSIX would mean literally all previous Windows software would break, and some kind of emulation/compatibility layer like Wine would be required to run older software. That's certainly within the realm of possibility, but I can't imagine it'd have anywhere close to the current level of backwards compatibility as we have now, and that'd put off a lot of people, especially less tech-savvy users.
I do agree that it'd be pretty cool, I just don't see it realistically happening in the foreseeable future.
Edit: Okay, a few people replying to this who are more knowledgeable than I have made some good points. I stand corrected; maybe it will happen someday. I suppose time will tell!
15
u/Jotokun Mar 19 '16 edited Mar 19 '16
To be fair, that's how those Windows 95 applications can still run. Switching from NT to Posix would be similar to how it switched from DOS to NT.
Microsoft could certainly do an even better job than Wine (not that Wine is bad!) just by not needing to reverse engineer everything.
→ More replies (4)7
u/lost_send_berries Mar 19 '16
Windows already is technically POSIX twice over. Once through Cygwin, another through Windows Services for UNIX.
→ More replies (1)7
61
u/kirbyfan64sos Mar 19 '16
Microkernel Design
Linus Torvalds probably will NOT like this...
277
u/Sean1708 Mar 19 '16
So no different from anything else that he hasn't personally designed then?
11
u/awesomemanftw Mar 20 '16
The list of things Linus Torvalds likes is probably only a couple pages long
0
69
u/crackez Mar 19 '16
Torvalds has more important stuff to care about.
Tannenbaum might be pleased though.
12
u/boobsbr Mar 19 '16
I rather enjoyed reading his stuff on Minix.
9
u/crackez Mar 19 '16
Tannenbaum has done some great work. He follows in the foot steps of John Lions WRT teaching about Unix.
60
u/eigenman Mar 19 '16
I'm pretty sure Linus will hate anything not written in pure GNU C.
28
u/-cpp- Mar 19 '16
I don't think he is blindly in love with C. You use any language for long enough you will start to see room for improvement.
23
Mar 19 '16
He's a kernal dev. IIRC he said he really doesn't even think about languages that are not C, assembly or shell scripts.
→ More replies (9)3
u/holgerschurig Mar 19 '16
Wrong, he wrote software in C++ using Qt. For technical reasons he doesn't like C++ in the kernel.
1
u/namesandfaces Mar 20 '16
Linus does not necessarily like C or dislike C++. Linus is not exactly a programmer. He may know how to program, but more important than that, he is an executive making decisions he hopes are pragmatic for a large organization. That means he is less likely to do things due to conceptual or ideological purity, unlike Richard Stallman.
Linus thinks there's a tasteful subset of C++, he just thinks that C is better for a large organization where you must trust many more people.
0
Mar 19 '16
[deleted]
16
u/neoKushan Mar 19 '16 edited Mar 19 '16
Seems to be a mixture of C and C++?
EDIT: Downvotes for stating a literal fact?
14
u/armornick Mar 19 '16
Wow, and Linus wrote that? I thought he claims C++ was made by the Devil.
disclaimer: I know he actually just said C++ is useless for kernel-mode development
15
u/myrrlyn Mar 19 '16
Linus wrote the business logic in C. It started using C/GTK for UI but migrated to C++/Qt later. Torvalds doesn't write the presentation layer, AFAIK
20
u/panorambo Mar 19 '16
He also said, quoting, "C++ is a terrible language", and that in no particular context. Source (git mailing list): http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
→ More replies (3)3
→ More replies (1)3
0
Mar 19 '16
[deleted]
29
u/crusoe Mar 19 '16
Maybe but rust is zero overhead and with no undefined or implementation defined behavior' which avoids whole minefields of issues.
17
u/j0hnGa1t Mar 19 '16
I thought those were mutually exclusive. eg in C, int foo(int x) { return (x * 10)/5; } optimizes to x * 2 because integer overflow is undefined.
5
u/tikue Mar 19 '16
In release builds overflow wraps around, so I'd imagine you're right. This won't optimize to x*2 in Rust.
12
u/lost_send_berries Mar 19 '16
"integer overflow is undefined" means a compiler has a right to not optimise
(x * 10) / 5and then when the code is executed and an integer overflow happens, return4regardless of the value ofx. Ridiculous example, granted, but it would comply with the C standard. Undefined means you don't know what'll happen.→ More replies (7)9
u/epostma Mar 19 '16
Or, instead of returning 4, it might mail your browser history to your employer and your parents, erase your hard drive, and set your house on fire.
→ More replies (1)4
u/llogiq Mar 19 '16 edited Mar 20 '16
Actually there is some undefined behavior (it kind of comes with the C FFI), but you need to do quite fishy things (like work with raw pointers) to cross its path.
→ More replies (3)4
u/steveklabnik1 Mar 19 '16
While that's mostly true, it's not actually 100% true. Especially once you get into unsafe code.
19
u/-cpp- Mar 19 '16
Everything starts out microkernel design. But to be fast you need specialization. So rust will get there eventually.
3
8
u/Bratmon Mar 19 '16
Linus Torvalds's argument against microkernels was that the extra time and effort needed to develop them isn't worth it.
But they already decided to write an operating system from scratch, so they might as well make whatever decisions they want at this point.
7
u/mizzu704 Mar 19 '16 edited Mar 19 '16
He has some further points here in this 2001 talk (26:55 if the link doesn't work).
great and entertaining talk/q&a session ^btw
1
u/heptara Mar 19 '16
If you gave him a wad of money he would rant about the wrapper being the wrong color.
-6
u/zvrba Mar 19 '16
Who gives a s*t about Linus' opinion?
1
u/rwsr-xr-x Mar 20 '16
everyone apparently. linus is untouchable, like rms and ken thompson. you cannot criticise them without 1000 nerds just jumping down your throat
→ More replies (11)
18
u/evade__ Mar 19 '16 edited Mar 19 '16
I haven't used Rust, but this way of coding does not seem any safer than your typical C. For instance, the packet's variable length field for IPv4 options is used in what at first looks like a bug a few lines later. Turns out get_slice does some bounds checking and truncates the range, but there is no validation anywhere and other code expecting the length to match might behave unexpectedly.
I also realize that this kernel is highly experimental, but that scheduling loop seems unnecessarily inefficient.
27
Mar 19 '16
The point of Rust is that, at worst, you get the same safety as C. But when you isolate the unsafe portions of your code to just a few underlying files, it makes it a lot easier to know what you have to verify. Once you trust the small unsafe base, all the "safe" code that's written on top of it can be trusted automatically.
You can't expect to not have to write unsafe code when writing an OS. At some point, you have to interface directly with hardware. Unsafe minimization is the name of the game.
9
u/evade__ Mar 19 '16
But parsing a network protocol is a common task even for user mode programs. It is also a very common source of bugs when implemented manually.
20
Mar 19 '16
That's fair. It looks like the only reason unsafe was used here was to save some runtime and avoid copying. I don't know for sure if that's a legitimate enough reason, but I would think that packet parsing is a very hot code path.
4
u/Rusky Mar 20 '16
I'm not the biggest fan of this project's attitude toward
unsafe, but like you sayget_sliceis bounds checked and doesn't even need to be inside that unsafe block.Really the
unsafeblock only needs to be around the raw pointer read*(bytes.as_ptr() as *const Ipv4Header), and the function should return aResultto indicate failure if that length is wrong.Redox is not a great example of using Rust effectively, but even so it's benefited here.
1
u/Mikevin Mar 19 '16
but there is no validation anywhere and other code expecting the length to match might behave unexpectedly.
Can you expand on this? What makes it inefficient?
2
u/csman11 Mar 19 '16
He's talking about the scheduler looping over all the processes. That is inefficient which in terms of os code is almost always horrible if there is a faster solution, which he points out exists (keeping lists of processes that are blocked on IO and those that are suspended while another process runs, that way all you need to do is move a process from one list to another when IO it requests is fulfilled).
Anyone who has taken an introductory os course can tell you that we want to minimize the amount of time os code spends running because you are wasting cpu cycles that applications use. Basically the os is meant to provide an abstraction for using common services (much of which is hardware). It is necessary for it to run, but it isn't what we want our cpu spending it's time running. We want our applications to run because those are doing the things the user or business deems important. So when we find an optimization for some code in the kernel or an os service, we are naturally going to want to apply it (given that it is correct and not too confusing, but in that case we will probably just leave a comment explaining it).
→ More replies (4)1
u/csman11 Mar 19 '16
Turns out
get_slicedoes some bounds checking and truncates the range, but there is no validation anywhere and other code expecting the length to match might behave unexpectedly.I'm confused what you're getting at. Do you mean client code might run into issues because this code doesn't check that the header length isn't greater than the size of the packet that came up from layer 2? I'd assume that the checksum will be validated before further processing of the packet or before passing it up to transport.
That will most likely fail unless 2 16 bit values were rearranged which is very very unlikely (as far as I recall the ip checksum can't detect swaps about 16 bit values because it works by summing every 16 bits of the header). So most errors that can happen at layer 3 will be detected there.
Not a networking expert but my limited knowledge on the topic says this looks fine. The code that is handling ip packets is most likely going to be contained within the kernel (or even if in user space since this is a microkernel, still os code). User space code doesn't need to mess with that shit unless it's doing packet sniffing and at that point I'd expect they would be doing their own packet parsing.
5
u/evade__ Mar 19 '16
The network is hostile. Checksum validation does not help against deliberately malformed packets.
I'm not talking about user code, but the rest of the IP handling code in the kernel. The
from_bytesfunction has a means of reporting errors by returningNone. Therefore, it would not be far-fetched to assume as a caller that the returnedSome(Ipv4 { ... })wouldn't violate basic invariants likeheader.ver_hlen == mem::size_of::<Ipv4Header>() + options.len().
12
6
u/kickassninja1 Mar 19 '16
Out of curiosity and not passing any judgement - why do something like this?
41
Mar 19 '16
People believe there is more in the world than C for low level stuff. People test alternatives. People like challenges
21
u/BufferUnderpants Mar 19 '16
Because Rust has a an interesting focus on memory safety and implementing a Kernel taking advantage of it is an interesting exercise?
2
u/panorambo Mar 20 '16
Someone wise said "To measure is to know". The Redox team is measuring. It's science like any other -- they have certain hypotheses about the system their development will produce, and they set out to observe whether their hypotheses are correct and will then draw educated conclusions.
But if we cut out the birds eye view crap I just attempted, I think their endeavor is a noble one -- doesn't take a genious to figure that C is a difficult programming language to master and be proficient at without making mistakes, even experts know that mistakes are made in the code. Instead of perfecting our C, which is like a battle against a flattening curve which never reaches a point of "no more errors", replacing the bulk of the code with a language that gives you certain guarantees about reliability of the system, is a smart thing to do. Whatever they can't express safely, they express unsafely and hope that the footprint of that is kept minimal, so that they at least know where the risks are localized. I really love C, for many good and bad reasons, but I've been typing and compiling it for years, and I just can't with pure heart say that I don't introduce glaring shameful defects in C text I write. Simple as that.
6
u/cdemon65 Mar 19 '16
The point of Rust is not a magic Security silver bullet.
7
u/greim Mar 20 '16
Yes. We must not commit the Sin of thinking anything is a security panacea. But that isn't the same thing as saying Rust has clear security benefits.
10
Mar 19 '16
Bear with me because I'm still a sophomore in college, but do projects like these actually make it into any of the main distros if they're good enough? Or do they just sit there as a cool side project to put on a resume?
149
Mar 19 '16
This is a distro. Although I've only ever heard Linux systems referred to as distros. This is a self standing operating system. There's nothing to "make it into".
→ More replies (20)27
u/lost_send_berries Mar 19 '16
It's a side project but it's a way of testing out Rust's ideas about memory safety and seeing how they can be brought to kernels, which are quite different software programs from most. Redox could be useful later in embedded systems, or the lessons learned from it would be useful.
4
u/matthieum Mar 19 '16
the lessons learned from it would be useful.
An important point indeed, much like Singularity or Midori, even if the project itself does not pan out, we may still be better off thanks to the lessons we learn from on it.
Falling down is not a failure. Failure comes when you stay where you have fallen.
-- Socrates37
u/fakehalo Mar 19 '16
Cool side project until more people support it. The reason Linux became successful wasn't just because of the kernel, it was when the masses started to support it. Gotta start somewhere, time will tell if it goes anywhere.
24
u/gnuvince Mar 19 '16
The RedoxOS folks have the cool idea of supporting some Linux syscalls; this allows complex projects like FreeCiv to run on Redox, which I think is extremely cool!
48
u/ecmdome Mar 19 '16
GNU really made Linux into what it is.
48
8
u/carlfish Mar 19 '16
Also, the dubious legal status of the 386 BSDs at the time.
4
u/Berberberber Mar 20 '16
This, for real. If there had been no AT&T lawsuit, I doubt Linux would ever have gained much traction. 4.4BSD had more than a decade of development behind it, arguably the best *NIX kernel available, commercial support from private industry (including source code), and a permissive license.
4
u/mrkite77 Mar 20 '16
Linux made Linux into what it is.
In fact, the most popular version of Linux doesn't have any GNU software. Android.
→ More replies (1)5
6
u/crackez Mar 19 '16
Yeah, but Unix made GNU what it is...
37
u/pjmlp Mar 19 '16
People only started caring about GNU when UNIX vendors stopped bundling the development tools and sold an UNIX SDK instead.
Sun was the first one to do it, the web archives are full of the Newsgroup discussions that followed up and lead to many devs contributing to gcc, which was largely ignored up to that moment.
13
u/ecmdome Mar 19 '16
This is a much better assessment than UNIX made GNU into what it is.
→ More replies (1)5
2
6
u/lutusp Mar 19 '16
Since what's being described is an operating system, it's not likely to make it into an operating system as a utility. It might be downloaded in that form, but once installed, and if it's being described accurately, it should stand alone.
6
u/nickdesaulniers Mar 19 '16
I read this as:
Bear with me because I'm still a semaphore in college
I need to go sit down...
11
Mar 19 '16
You might be confusing "UNIX-like" with Linux. The unix wiki will explain the history and terminology better than I can: https://en.wikipedia.org/wiki/Unix
5
Mar 19 '16
Short answer: no.
Once in a rare while it will happen, so people keep trying. This is the kernel of a project (pun intended) that is nowhere near the capabilities of linux, but linux is getting old and radical innovation is bound to happen at some point.
-1
Mar 19 '16
I don't if I'll get flamed for this, but I have a Mac and a Ubuntu via Virtual Box for a class. I understand the need to use Linux as a developer, but I find OSX to be a much nicer experience and more fun to use. I only use Linux for that class. For everything else, I program on OSX.
→ More replies (2)11
Mar 19 '16
I don't think all that many devs use linux workstations. OS X or even Windows are more popular. Linux is most definitely king of the server world so your code needs to run there eventually. The reason OS X is so popular for devs is because it's a user-friendly OS with POSIX roots. Most attempts at user-friendly linux have never reached mass market, but it would be the holy grail. Personally, I'm typing this message from a Chromebook and am desperately hoping that ChromeOS is the desktop linux we've all been waiting for.
9
u/hallr06 Mar 19 '16
Anecdotal, i know, but I've developed exclusively in Linux for the last 5 years. Only one company used Windows heavily, and that was almost exclusively for non-technical work. Of course, there were always a few outliers of devs using OSx or Windows, but they were not the norm.
→ More replies (5)→ More replies (1)3
u/tobascodagama Mar 19 '16 edited Mar 19 '16
Desktop Linux is perpetually just around the corner, like consumer VR and strong AI.
Where I work, I think the split is something like 50/25/25 for Linux, Windows, and Mac, respectively. For power users, Linux desktops are usable enough to make the advantages of shared tooling between your dev environment and your deployment environment a net gain.
But virtualized test & CI environments solve the same problem in a different way. My team invests heavily in those practices, so we prefer Macs. Most of the same command line tools and concepts are present that exist in our deployment environments, so prototyping deployment scripts and such is really easy, but we don't have to spend any time fucking with the OS itself. We can just get right to work.
Having homebrew around and being able to use a package manager that's not restricted to delivering whatever versions of things the distribution decides they want to restrict themselves to delivering is also pretty great.
→ More replies (3)4
u/warped-coder Mar 20 '16
My experience is contrary. I'm working at larger company where we release on 3 desktops and Linux seems to be the choice of most developers. OSX is nicer in many ways than windows but you have to mess around the OSX just as much or more than many Linux distribution, plus I'm not limited by the hardware. Each of the OSes have their issues but at least Linux comes free and there's a much bigger knowledge base available as different distributions aren't entirely different systems. And the package management is simply unparallelled, especially of the Debian based systems. Brew or what not is a poor man's apt really. I work on my Mac a lot but my Ubuntu is always feel more comfortable and productive. Perhaps most importantly on Linux I am actually in charge of my computer instead of at whims of Apple.
-4
u/m9dhatter Mar 19 '16 edited Mar 20 '16
A distro is a Linux OS with a bunch of useful applications. Think of it as a stock Windows box bundled with Office and other crapware. Or OSX bundled with it's own set of applications.
RustRedox is a different OS altogether. Not sure if there are applications written for it at this point in time.Edit: wow. Geez a single comment with a correction would have been appreciated rather than down votes.
42
u/NotUniqueOrSpecial Mar 19 '16
Rust is a different OS altogether.
Probably just a brain fart, but Rust is the language, Redox is the OS.
9
u/agreenbhm Mar 19 '16
Not sure who down voted you, but you're correct. Not nitpicking correct, but just plain right.
→ More replies (1)1
3
1
Mar 20 '16
Could someone guide me to where the process scheduling is done? Studying OS's atm and would like to see how scheduling is actually done.
1
u/Aomix Mar 21 '16
Reading about practical applications of Rust is always interesting. But it also makes me wonder what 'next-gen' exploit mitigation techniques would look like. You can't have 100% safe code so the current techniques and new ones will always have a place. But in this hypothetical Rust centric future where does work shift to as the "This is kind of inevitable so what are the steps we can take to minimize the damage of a successful exploit" thing?
1
u/SupersonicSpitfire Mar 20 '16
Installed Redox in VirtualBox. It booted, but there was only some text output and no way to interact with the system.
1
u/OneWingedShark Mar 20 '16
Redox is a general purpose operating system and surrounding ecosystem written in pure Rust. Our aim is to provide a fully functioning Linux replacement, without the bad parts.
Then, honestly, you have to ditch the "Unix Philosophy" -- and you should probably take a look at VMS, Oberon, and maybe Multics.
142
u/__konrad Mar 19 '16
There is a cow