Redox OS Crash Challenge • Hacker News Board

Re: Redox OS Crash Challenge

#41

Post by conradev » Sun, Jan 21, 2018, 11:07 PM UTC

surajrmal wrote: post #4

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.

> 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. The difference is what happens when a bug is encountered. If it is caught a…

Panics may be safe and unwind nicely, but they can still, for example, be triggered in an untested code path to DOS a system.

That's one reason that people run AFL against safe Rust.

Re: Redox OS Crash Challenge

#42

Post by SAI_Peregrinus » Sun, Jan 21, 2018, 11:17 PM UTC

Nomentatus wrote: post #34

fny wrote: post #22

Earlier quoted context omitted.

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 nece…

The idea that something can be "necessary but not sufficient" comes up a lot, and is very often misunderstood.

Rust-like guarantees are necessary but not sufficient for safe systems.

Re: Redox OS Crash Challenge

#43

Post by nh2 » Mon, Jan 22, 2018, 12:06 AM UTC

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.

I think much worse is forgetting to check the size returned by a read() or write() call, especially when dealing with sockets.

Unchecked malloc() crashes very easily, data chopped off in the middle usually triggers problems on the /other/ side.

Re: Redox OS Crash Challenge

#44

Post by Ar-Curunir » Mon, Jan 22, 2018, 12:10 AM UTC

snvzz wrote: post #33

I'd rather trust something with a formal proof, such as seL4. https://sel4.systems

The two aren't mutually exclusive.

Re: Redox OS Crash Challenge

#45

Post by swsieber » Mon, Jan 22, 2018, 12:43 AM UTC

erickt wrote: post #30

eat_veggies wrote: post #28

Earlier quoted context omitted.

Do you recommend any resources to learn rust?

The official rust book [1] is a great place to start. So are the exercism tutorials [2] [1] https://doc.rust-lang.org/book/ [2] http://exercism.io/languages/rust/about

Version 1 or 2 of the rust book?

Re: Redox OS Crash Challenge

#46

Post by andrewstuart » Mon, Jan 22, 2018, 2:00 AM UTC

This was the output I got when I followed the instructions from the book: - what should I have seen? Can you suggest what I can do to make it work?

  (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~# qemu-system-x86_64 -serial mon:stdio -d cpu_reset -d guest_errors -smp 4 -m 1024 -s -machine q35 -device ich9-intel-hda -device hda-duplex -net nic,model=e1000 -net user -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0 -enable-kvm -cpu host -drive file=redox_0.3.4.bin,format=raw  -nographic
  pulseaudio: pa_context_connect() failed
  pulseaudio: Reason: Connection refused
  pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
  ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
  ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
  ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory
  ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
  ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
  ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory
  ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  audio: Failed to create voice `dac'
  ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
  ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
  ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory
  ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize ADC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
  ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
  ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory
  ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize ADC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  audio: Failed to create voice `adc'
  qemu-system-x86_64: terminating on signal 15 from pid 8287
  (venv3.5) root@ubuntu-s-1vcpu-1gb-nyc1-01:~#

Re: Redox OS Crash Challenge

#47

Post by quotemstr » Mon, Jan 22, 2018, 2:04 AM UTC

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.

Using exceptions solves that problem and many others besides; it's a shame they're not currently in fashion. But you do end up needing them, so in Rust, we end up with error codes _and_ exceptions (but spelled "panic").

Re: Redox OS Crash Challenge

#48

Post by quotemstr » Mon, Jan 22, 2018, 2:07 AM UTC

steveklabnik wrote: post #19

hedora wrote: post #18

Earlier quoted context omitted.

I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callb…

Rust is significantly different with regards to this stuff: * There is no reflection API * Exceptions don't exist * There's no subtyping, so ClassCastExceptions can't exist. (There's subtyping with lifetimes, and you can't cast them, so that doesn't count) * final doens't exist That said, every language has things that you don't realize; we did have a sort of similar moment to this stuff before 1.0 with the "leakapoc…

> Exceptions don't exist

They're called panics.

> There's no subtyping, so ClassCastExceptions can't exist.

Any sort of polymorphism opens you up to the possibility that code that's written to take abstract type A, implemented concretely in B and C, implicitly expects a B and blows up when it gets a C. Rust doesn't solve this problem.

> final doens't exist

Sure it does. It's just implied, and not-final has to be spelled out. This is one thing Rust did that I do agree was a good move. The other stuff? I remain unconvinced, especially with respect to structural subtyping.

Re: Redox OS Crash Challenge

#49

Post by imron » Mon, Jan 22, 2018, 2:11 AM UTC

quotemstr wrote: post #47

ModernMech wrote: post #37

Earlier quoted context omitted.

> 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.

Using exceptions solves that problem and many others besides; it's a shame they're not currently in fashion. But you do end up needing them, so in Rust, we end up with error codes _and_ exceptions (but spelled "panic").

Not in C (which does not have exceptions) and not in C++ when doing what the parent suggested (calling malloc, not new).

Re: Redox OS Crash Challenge

#50

Post by kvark » Mon, Jan 22, 2018, 2:15 AM UTC

quotemstr wrote: post #47

ModernMech wrote: post #37

Earlier quoted context omitted.

> 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.

Using exceptions solves that problem and many others besides; it's a shame they're not currently in fashion. But you do end up needing them, so in Rust, we end up with error codes _and_ exceptions (but spelled "panic").

Well, error codes are not special constructs in any way. And exceptions can be easily overused. So you have to draw the line somewhere. Rust just choose the balance where facing an exception is truly exceptional :)