Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

My understanding is this was not a case of null pointer access that could be caught by a compiler really... but of a corrupt data file making a mess all over the place... running in kernel space, where no segfault is safe.

The root issue is giving privileged access to a business entity you think you can trust, but clearly can't.

I'm a fulltime Rust developer, but I don't think Rust saves you here.

View on HN

Wouldn't a strongly typed language like rust sill catch a bad datafile?

E.g. loading it would require you to setup a maximal size and a valid configuration struct?

It could.

We haven't seen the code but it could be something like:

  char *ptr = parsefile(file_we_released_without_testing);
  if(ptr[0]=='A') { } // BSOD loop

parsefile returns NULL unexpectedly.

So this style of error can be addressed by using a safe language. Or static analysis. Or code reviews. Or not doing this stuff in the kernel. Or formal methods. Or fuzzing.

As someone else said you likely can't easily use Rust for Windows kernel modules/drivers. I'm sure a strong enough engineering team could do it (e.g. transpile Rust to C) but I'm not sure it's the biggest engineering problem CrowdStrike has. Microsoft has a complete tool-chain for developing these and it's usually C/C++ or assembly.

unhandled null in rust will still cause panic. still cause the bootloop.

I'm not a Rust expert but wouldn't you pick some ("null-safe") type that can't be null in Rust? A reference?

i dont think it matters, if you have any exception in the critical boot part, you will end up with this. Rust cannot fix this. Microkernels might.

Something like this Go snippet:

  func parsefile(string) string {
  }

  func thatfunctionthatcrashedinC() {
      defer func() {
      if err := recover(); err != nil {
        log.Println("panic occurred:", err)
      }
    }()
    result := parsefile(badfilethatcrashesC);
    if result[0] == 'A' {
    }
  }

so... using a type that can't be nil. recovering from runtime panics (you have to do that but this can be enforced by standards and also it can happen up the stack for all code, e.g. like http handlers do by default in the Go standard library). More importantly these errors are not segfaults in Go, i.e. there's "exceptions" you can and should catch and there are exceptions you can't.

You have all that in C++ too. Exceptions are near zero cost and used everywhere, sometimes even in embedded stuff too.

Sure. I speak C++ ;) You can do this in C++ but I think it's generally more crash prone than Go. Based on personal experience of ~20 years of C++ and ~10 of Go I've debugged many a core dump in C++ and I think zero in Go. You can restrict yourself to the somewhat safer parts of C++ for sure.

If what you say is true -- OK. Then would you say that the tweet posted earlier that showed the NULL pointer access was incorrect or misleading?

Null pointer access caused by bad data is entirely conceivable... esp when you overwrite parts of kernel memory with nulls.

I see. That doesn't make it better though, and OK let's forget about other languages.

I mean that the least you can do before pointer dereference is just check for several bad sentinel values, NULL being one of them.

Seems like a rather amateur mistake to me.

From that point of view, there are several million amateurs, some of them quite highly paid, out there writing terrible code.

Well, that statement is 100% true.

I've been an idiot as well in the past. Happily some of us actually learn though!

Reply on news.ycombinator.com