4 ms·

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 th

• pdimitar 2y ago
  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?
  • cmrdporcupine 2y ago
    Null pointer access caused by bad data is entirely conceivable... esp when you overwrite parts of kernel memory with nulls.
    • pdimitar 2y ago
      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.
      • lambdaone 2y ago
        From that point of view, there are several million amateurs, some of them quite highly paid, out there writing terrible code.
        • pdimitar 2y ago
          Well, that statement is 100% true. I've been an idiot as well in the past. Happily some of us actually learn though!
• bpfrh 2y ago
  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?
  • YZF 2y ago
    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.
    • ArtixFox 2y ago
      unhandled null in rust will still cause panic. still cause the bootloop.
      • YZF 2y ago
        I'm not a Rust expert but wouldn't you pick some ("null-safe") type that can't be null in Rust? A reference?
        • ArtixFox 2y ago
          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.
          • YZF 2y ago
            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.