Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redox – A Unix-Like Operating System Written in Rust

redox-os.org

Post reply on HN
Print view View original

141–150 of 215 posts

Re: Redox – A Unix-Like Operating System Written in Rust

#141

Post by carussell »

teamhappy wrote: post #12
qz_ wrote: post #9

I'm pretty impressed that 37 people are capable of writing an entire OS with a gui in under a year. Looks really cool.

Operating systems aren't that big, and if you know your stuff, I'm sure it's not too hard to pull off. Here's an example I borrowed from StackExchange: According to cloc run against 3.13, Linux is about 12 million lines of code. 7 million LOC in drivers/, 2 million LOC in arch/, and only 139 thousand LOC in kernel/. ( http://unix.stackexchange.com/a/223753 ) Edit: Would be nice to have the numbers for the latest Mini…

> Does anybody know how big their core team is?

Right now it's about 2.

Re: Redox – A Unix-Like Operating System Written in Rust

#142

Post by nickpsecurity »

Animats wrote: post #126
nickpsecurity wrote: post #98

Earlier quoted context omitted.

I was worried a whole UNIX might be too big a project so I gave him old school recommendations before. Essentially told him to make a split system that lets you run on tiny kernel bare metal, run UNIXy apps with different API, and let them communicate through some IPC mechanism. That way, like security & MILS kernels, people can write security critical components in isolated partitions with checks at interfaces. Alre…

A web server gets big, complicated, has lots of add-on parts, and has performance constraints. Small routers, DNS servers, and BGP servers are small, closed systems that should Just Work. You want to get them working, lock the code into read-only memory, and forget them.

Kbenson gets what Im saying with a simple, static server for interfaces and such. I totally agree that a more feature-rich server, esp tolerant of hostile networks, has all kinds of performance and structuring issues that arent easy to do. Got to learn tat the hard way applying B3 class assurance to one I built. The FSM's and info flows piled up quicker than most would think.

Re: Redox – A Unix-Like Operating System Written in Rust

#143

Post by bluejekyll »

polyfill wrote: post #119
Animats wrote: post #84

Very nice. It was time to do this. There are three near-term products to develop on this: - A small router (home/small office, not data center) - A DNS server - A BGP server Those are standalone boxes which do specific jobs, they're security-critical, and the existing implementations have all had security problems. We need tougher systems in those areas.

This may be helpful for the DNS server https://github.com/gtadam/rust-dns

I'm working on something: https://github.com/bluejekyll/trust-dns

I'm in the midst of implementing DNSSec right now, I've got RRSIG and DNSKEY validation back to the root now. I'm working on negative query validation right now, NSEC and NSEC3. Maybe a new release in a few weeks after that is supported.

Re: Redox – A Unix-Like Operating System Written in Rust

#144

Post by fghfghgfhfg »

nickpsecurity wrote: post #125
polyfill wrote: post #119

Earlier quoted context omitted.

This may be helpful for the DNS server https://github.com/gtadam/rust-dns

Interesting. So will this for anyone brave enough to use SPARK and Rust: http://ironsides.martincarlisle.com/ IRONSIDES uses SPARK to show freedom of exceptions or single-packet DOS. A translation to Rust would probably preserve most of those properties. I also thought a parallel development between Ada2012/SPARK and Rust would be interesting to see if one set of checkers catch something another misses in same piece…

My understanding is that Rust doesn't have so much to offer Ada/SPARK. I haven't looked that hard at Rust though, so maybe I've overlooked some of it's features.

You have to jump through the same sort of hoops in Rust as you do C++ to get the sort of basic type safety found in Ada/SPARK. Rust doesn't so much have a focus on safety and correctness in general, as a focus on memory safety.

Admittedly, Ada/SPARK doesn't make the kinds of guarantees that Rust does about memory. However, accessibility checks help prevent dangling pointers and the use of memory subpools can avoid the need for explicit frees.

Additionally, Ada offers some features like the ability to return a dynamically sized array as if it were on the stack which helps reduce how often memory needs to be manually managed. I believe SPARK may not allow this sort of thing though.

I'm also not sure why you would want to abandon the actually verified properties of Ironsides for a hope those properties remained in an unverified port.

Re: Redox – A Unix-Like Operating System Written in Rust

#145

Post by jotux »

teamhappy wrote: post #12
qz_ wrote: post #9

I'm pretty impressed that 37 people are capable of writing an entire OS with a gui in under a year. Looks really cool.

Operating systems aren't that big, and if you know your stuff, I'm sure it's not too hard to pull off. Here's an example I borrowed from StackExchange: According to cloc run against 3.13, Linux is about 12 million lines of code. 7 million LOC in drivers/, 2 million LOC in arch/, and only 139 thousand LOC in kernel/. ( http://unix.stackexchange.com/a/223753 ) Edit: Would be nice to have the numbers for the latest Mini…

I worked at a company that made POS terminals on the OS development team. We had a proprietary OS based loosely on UNIX that was ~100KLOC (kernel). It was largely designed by 3-4 core developers and maintained by ~12 embedded software engineers (in addition to drivers, apps, UI, etc).

Re: Redox – A Unix-Like Operating System Written in Rust

#146

Post by grok2 »

bluejekyll wrote: post #143
polyfill wrote: post #119

Earlier quoted context omitted.

This may be helpful for the DNS server https://github.com/gtadam/rust-dns

I'm working on something: https://github.com/bluejekyll/trust-dns I'm in the midst of implementing DNSSec right now, I've got RRSIG and DNSKEY validation back to the root now. I'm working on negative query validation right now, NSEC and NSEC3. Maybe a new release in a few weeks after that is supported.

Having used Rust for this, what are your thoughts about how Rust fares for such tasks -- is coding this in Rust better than using C; do you think you are having fewer problems in the end-product as compared to if you had used C. What are the kinds of issues that annoy you about Rust for this? Does the promise of Rust hold up? I am trying to see if I should use Rust for network programming and want to find out how Rust feels for these kinds of projects.

Re: Redox – A Unix-Like Operating System Written in Rust

#147

Post by jaltekruse »

kpozin wrote: post #132

I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might ne…

I only took a brief look over the code to try to find what documentation is actually there, but I managed to find this

https://github.com/redox-os/redox/blob/master/kernel/fs/url....

On your question of how typical a lack of system-internal documentation is in systems projects, the answer from my experience is unfortunately more common than it should be. There are a bunch of usage and design patterns that cannot be expressed regardless of the language you are using. I know very little about Rust, but I work mostly in Java, which is safer than many other languages (less flexible than interpreted or dynamic languages, less dangerous than C/C++). Even java, which has interfaces and strict typing can save you some of the more mundane unit tests and input validation code, has a bunch of design patterns on top of the core language. Projects could serve themselves well to document their code well to allow new contributors to look at any of the code and reasonably modify it to fix a bug or add a feature.

Re: Redox – A Unix-Like Operating System Written in Rust

#148

Post by XorNot »

amelius wrote: post #76
Manishearth wrote: post #34

Earlier quoted context omitted.

There's a bit more info here: https://github.com/redox-os/redox/wiki/URL

Very interesting. The only odd part is that the modules (drivers) themselves are not referenced by URL, but only by a simple word (in the example "port_io"). Also, I wonder how we could combine drivers. For example, (theoretically) instead of using "https" as driver, we could compose it as "HTTP over TLS over TCP", and change any of those subcomponents as desired. With URLs this might become clumsy.

It depends how you want to express the hierarchy - URLs say "this is my transport system, and this is my address".

But you could propose doing: tcp+tls+http://www.some.url/?options=here

if you were okay with that. The problem creeps in when that tls fragment needs options and a path of it's own.

Re: Redox – A Unix-Like Operating System Written in Rust

#149

Post by burfog »

bsder wrote: post #135
burfog wrote: post #128

Earlier quoted context omitted.

In other words, like GNU HURD. That design is very very hard to make correct and fast. Correctness suffers because the UNIX API has all sorts of interactions between different parts. This includes atomicity. It's a bear to get this right with IPC. Performance suffers because you are unable to effectively share data structures. This too relates to the interactions between different parts of the UNIX API. Look, there i…

> In other words, like GNU HURD. That design is very very hard to make correct and fast. There are plenty of counterexamples to slow microkernels nowadays. In addition, we trade speed for things like garbage collection. I'd happily trade some speed for increased security.

Every example of a "fast" microkernel has either ripped out expected functionality (debug traces for example) or simply been the first to make an optimization that can be applied to monolithic kernels as well. Fundamentally, microkernels are slower. A bit of thought should make it clear that this can not be otherwise. No matter how fast you can pass a message, it's still faster to not pass a message at all. Also, the overhead of TLB misses when changing MMU mappings is huge. Microkernels can only win when they compete against badly-optimized monolithic kernels and there is no technique that can get past this fundamental truth.

Re: Redox – A Unix-Like Operating System Written in Rust

#150

Post by burfog »

nickpsecurity wrote: post #137
burfog wrote: post #128

Earlier quoted context omitted.

In other words, like GNU HURD. That design is very very hard to make correct and fast. Correctness suffers because the UNIX API has all sorts of interactions between different parts. This includes atomicity. It's a bear to get this right with IPC. Performance suffers because you are unable to effectively share data structures. This too relates to the interactions between different parts of the UNIX API. Look, there i…

I was talking about systems like KeyKOS and GEMSOS fielded in production before Hurd was a thing. Then, systems like QNX, OKL4, BeOS, Minix 3, and others that largely removed performance issues often with self-healing and legacy app support. Actually, BeOS and QNX in Blackberry Playbook outperformed monolithic competitors. These altogether long proved our approach builds reliable, fast-enough systems with more securi…

No, those do not perform well. They are just less horrible than GNU HURD. When you apply similar optimization and implement similar functionality, monolithic kernels always win. It cannot be otherwise; think about it.

Self-healing is generally a security problem. It gives the attacker a second chance. It's also generally a failure. You might think you can restart, but there are huge problems: Instead of a crash, you may get a memory leak or hang. Hardware may be in a strange state, needing a power cycle to restart. Other things start failing once one driver is down. Most systems are unable to keep DMA from scribbling all over everything in RAM, and probably all are unable to keep it from scribbling all over a filesystem.

Tanenbaum is biased. It's time to move on.

Post reply on HN