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

Redox OS Crash Challenge

github.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Redox OS Crash Challenge

#31

Post by EtDybNuvCu »

tscs37 wrote: post #11
infinity0 wrote: post #7

Earlier quoted context omitted.

The kernel faulting is effectively burning down. In modern systems there is the concept of "isolation", if you give bad input to one program (e.g. the shell) the kernel shouldn't fault (taking down unrelated programs with it).

There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.

Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation.

Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted....

The Monte language's manual starts with a tutorial and an explanation of what capability-safe languages do: http://monte.readthedocs.io/

Re: Redox OS Crash Challenge

#32

Post by tscs37 »

EtDybNuvCu wrote: post #31
tscs37 wrote: post #11

Earlier quoted context omitted.

There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.

Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanatio…

That's all nice but what if you have a CPU bug like Spectre?

Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isolation.

The documentation on Monte also mentions that it is rather slow and requires memory management, two properties that simply do not exist in kernel space.

Writing a kernel is like writing a modern web browser except if you get it wrong the malicious program can access everything, all webpages, all the history and send your mom rude jokes on facebook after literally setting your computer on fire.

So you can't simply say "we will never break isolation", you must question "in the absolutely infinitely small occurence that isolation breaks, what do we do?". A Kernel must be prepared to deal with such a possibility. Even if it "cannot happen".

Re: Redox OS Crash Challenge

#34

Post by Nomentatus »

fny wrote: post #22
azdle wrote: post #10

Earlier quoted context omitted.

I don't see anything in the link that seems to imply that they think Redox OS is going to be crash free? In fact this seems to be the opposite, it looks to me like they're looking for bugs to squash.

The OP isn't making a claim about anyone involved in Redox, but rather the general perception of Rust, particularly among non systems programmers. I tend to agree. I've shook hands with a lot of people that see Rust as a panacea rather than a mitigation strategy.

To my mind Rust is neither a panacea nor a mere mitigation strategy. It (or another language like it) is a necessary condition for anything like generally safe (not perfect) computing.

Please don't jump to the conclusion that someone who thinks that Rust isn't just one more mitigation strategy is an addled fanboi who thinks it's a total panacea and snake oil. That is NOT what they're saying. They are saying it's necessary for robust computing and I think they're right about that.

I'm quite tired of being instantly and vehemently misunderstood on this point so often, personally. So many people seem eager to put not just words but whole chapters in my mouth, even at the cost of using rather rotten logic to accomplish that. Those of us with considerable respect for Rust DO indeed understand that a necessary condition for genuinely safer computing is not a sufficient condition - but I do sometimes wonder if those who have less interest in Rust and sneer at anything resembling enthusiasm for it, have recognized this distinction, or have gotten that far in their thinking.

Re: Redox OS Crash Challenge

#36

Post by pohl »

davisdude wrote: post #21

Related: the Changelog podcast did a really good interview with the developer[1]. It's pretty long but worth the listen IMO. [1]: https://changelog.com/podcast/280

I listened to this last night; it’s great.

Re: Redox OS Crash Challenge

#37

Post by ModernMech »

geofft wrote: post #25
halayli wrote: post #2

Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. No cynicism intended, just an observation from what I see around.

> There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. Sure, but there are also plenty of improvements in Rust that aren't about memory safety. For instance, there's the improved type system over C or C++ (tuples, enums, traits, etc.), related features like pattern-matching on enums and trait-based error handling (the question-mark operator), and a macro system tha…

> like forgetting to check error returns

One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Kind of the worst of both worlds.

Re: Redox OS Crash Challenge

#38

Post by zerokernel »

tscs37 wrote: post #32
EtDybNuvCu wrote: post #31

Earlier quoted context omitted.

Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanatio…

That's all nice but what if you have a CPU bug like Spectre? Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isola…

That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security.

Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure that isolation (or more generally, specification invariants) does not break in any reachable system state.

Re: Redox OS Crash Challenge

#39

Post by tscs37 »

zerokernel wrote: post #38
tscs37 wrote: post #32

Earlier quoted context omitted.

That's all nice but what if you have a CPU bug like Spectre? Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isola…

That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security . Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure…

Even a perfect kernel will have to crash.

Something like Rowhammer can turn perfectly written code into malicioous gadgets for an attacker. Until ECC or preventative measures becomes widespread in consumer hardware, this attack will remain viable.

Additionally, cosmic rays may at any time write arbitrary data into memory. In these situations it is perfectly reasonable to crash the machine if essential datastructures were affected.

Or suppose you just received a MACHINE CHECK exception, the type of interrupt which essentially just tells the OS that the machine is no longer capable of operating in it's current state.

This isn't all about an attacker gaining privilege, the mere act of crashing the kernel in a hostile or other event (cosmic rays, voltage fluctuation) which leads to corruption or compromise of the continued operation of the machine is perfectly acceptable and normal.

Re: Redox OS Crash Challenge

#40

Post by geofft »

ModernMech wrote: post #37
geofft wrote: post #25

Earlier quoted context omitted.

> There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. Sure, but there are also plenty of improvements in Rust that aren't about memory safety. For instance, there's the improved type system over C or C++ (tuples, enums, traits, etc.), related features like pattern-matching on enums and trait-based error handling (the question-mark operator), and a macro system tha…

> like forgetting to check error returns One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Kind of the worst of both worlds.

Yes! In fact I'd argue that null-pointer dereferences are not a memory-safety bug the way buffer overflows / use-after-frees / etc. are, they're a type-safety bug. It's not that NULL is a currently-invalid pointer, it's that NULL is not a pointer at all - it's a value that's been stuffed into the pointer type because C has no better way to represent this. The actual return type of malloc is the set of all possible pointers along with NULL, a separate thing. Passing it to code that only expects something from the set of all possible pointers should require you to check for NULL and do something else instead.

If you want to optimize memory layout by reserving memory address zero, sure (and Rust's Option does exactly that), but at the language level, you shouldn't be able to use NULL as a pointer any more than you should be able to use 0.0 or '\0' or false as a pointer.

Post reply on HN