3 ms·

There is no reason to not use Rust for these systems anymore. It's why the US Government is pushing so much for Rust adoption. We're going to keep seeing these

There is no reason to not use Rust for these systems anymore. It's why the US Government is pushing so much for Rust adoption. We're going to keep seeing these horror stories until C/C++ go away.

victor106 2y ago
> It's why the US Government is pushing so much for Rust adoption. Can you provide any references for this?
- timschmidt 2y ago
  He's likely referring to this: https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre...
- RockRobotRock 2y ago
  https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
- kevindamm 2y ago
  They may be referring to DARPA's research project TRACTOR: https://www.darpa.mil/program/translating-all-c-to-rust https://www.darpa.mil/program/translating-all-c-to-rust
- AlotOfReading 2y ago
  There's been a number of reports released by the government that recommend adopting memory safe languages as opposed to C/C++. The White House put out a memo [0] for example, and NIST has this page [1]. Since there are no other systems languages with widespread developer mindshare, some people see these as primarily recommending Rust. [0] https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/memory-safety-statements-of-support/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/mem... [1] https://www.nist.gov/itl/ssd/software-quality-group/safer-languages https://www.nist.gov/itl/ssd/software-quality-group/safer-la...
  - jimbob45 2y ago
    What about MISRA C and C++ with static analysis tools? Also all GC languages would pretty easily solve the problem including Java and C#.
    - AlotOfReading 2y ago
      It's perfectly possible to write the crowdstrike issue in C/C++ code that will pass any MISRA checker, because MISRA checkers are unable to verify conformance with the standard. It basically says "don't do this" and leaves it up to the developer to ensure. Static analysis tools (broadly) are not powerful enough to ensure memory safety for nontrivial programs without a high developer burden in the form of annotations or restricted language subsets. GC languages are generally not appropriate for kernel level systems programming like crowdstrike was doing. Java has some history in this space, but generally without niceties like garbage collection that typical developers are used to.
  - echelon 2y ago
    > some people see these as primarily recommending Rust. That's not the reason. The DoD really is focused on Rust [1, 2]. [1] https://www.darpa.mil/program/translating-all-c-to-rust https://www.darpa.mil/program/translating-all-c-to-rust [2] https://www.darpa.mil/news-events/2024-07-31a https://www.darpa.mil/news-events/2024-07-31a
    - AlotOfReading 2y ago
      The federal government is a lot bigger than even the DoD, and the other agencies (e.g. NIST as linked above) have been very careful to make sure they aren't only recommending Rust, even if it's clearly a major alternative.
- notarealllama 2y ago
  If you follow CISA vulns and guidelines, it's all industrial controllers getting hacked and pushing for memory safety for like a year straight. (On a side note, pleasantly surprised to see a Linux kernel android bug today)
- keithalewis 2y ago
  We're from the Government and we're here to help. You need a license to operate a backhoe, but not to write software.
AdieuToLogic 2y ago
> There is no reason to not use Rust for these systems anymore. While Rust is a fine language, there are others which may be better suited for systems which have a global impact such as CrowdStrike does. Ada: https://en.wikipedia.org/wiki/Ada_(programming_language) https://en.wikipedia.org/wiki/Ada_(programming_language) SPARK: https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) I am an advocate for neither and only reference their applicability for this problem domain based on the languages' design intent.
MaulingMonkey 2y ago
>> According to the RCA, the essence of what happened was an index out of bounds While Rust's behavior of panicing is saner than C++'s behavior of undefined behavior for a typical index out of bounds bug (`slice[index]`), I would imagine it'd still result in BSODs and outages in a kernel context. Admittedly, safe bounds checking (`slice.get(index) → Option<T>`) might be easier in Rust than in C++, but it's not a given that a RIIR would've avoided this bug.
MBCook 2y ago
Oh who cares about Rust. This could have been written in many different languages safely, including C/C++. Would it have been easier in Rust? Maybe. But it's also a legacy codebase. So we shouldn't be surprised it wasn't in Rust. There are SO MANY things that went wrong. They don't even seem to care about half of them. Ok, it wasn't tested. It wasn't staged. It wasn't a slow roll-out over hours. It wasn't verified from the deployment servers. How about why is it parsed in kernel space at all? I didn't see that listed. Why didn't you have a mechanism to catch faulty updates at runtime and flag them so that you'd be able to survive the next boot? Mark somewhere on the FS "I'm loading #19583". If you boot up and find that, it means you failed, so skip it next boot. Succeed? Remove the mark. Tada. Resiliency. Why are you even doing this stuff yourself? There are Microsoft APIs for a bunch of this stuff that would have helped reduce risk. Oh, because your code is deployed on XP and up and you don't want to have 2 or 3 versions? That went well didn't it. I bet if you were using those you wouldn't have crashed the kernel space. Do you fuzz? We know you don't. You broke Windows. You broke Macs. You broke Linux. You keep doing this. You're not good at being resilient. You had to face-plant in front of the entire world before you decided to do something. I didn't see fuzzing mentioned. Those mitigations you propose are not enough. They'll help, but you're still vulnerable. You're supposed to be a _security company_, I'd expect a better list of how to secure software from a security company. By all means, use Rust or Swift or (insert other memory safe language) if you want. That's smart. But if their existing kernel module had no UB and buffer overruns, it would still be doing things a kernel module shouldn't. The language involved is just a very tiny part.
- aeyes 2y ago
  > Oh, because your code is deployed on XP and up Not even, it only runs on 7 / 2008 Server and up.
- jiggawatts 2y ago
  > ...it means you failed, so skip it next boot. Succeed? Remove the mark. Tada. Resiliency. Better yet, it's high time that PCs booted like (some) mobile phones do: there's two copies of the OS. The running copy is read-only. The other copy can only be replaced with a monolithic "image" that has is validated with a HS256-based digitally signed Merkle hash. Either the entire image is bit-for-bit valid, or it is rejected. If booting to the new image fails twice, automatically roll back to the previous known-good image. This isn't "hard", it isn't even that much work. Heck, Windows can already boot from WIM images and VHDX disk images! The code is already in there, it just needs to be turned on.
jki275 2y ago
Rust isn't a panacea, and the US Government really isn't pushing for Rust adoption.

There is no reason to not use Rust for these systems anymore. It's why the US Government is pushing so much for Rust adoption. We're going to keep seeing these horror stories until C/C++ go away.

victor106 2y ago

> It's why the US Government is pushing so much for Rust adoption. Can you provide any references for this?

timschmidt 2y ago
He's likely referring to this: https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre...
RockRobotRock 2y ago
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
kevindamm 2y ago
They may be referring to DARPA's research project TRACTOR: https://www.darpa.mil/program/translating-all-c-to-rust https://www.darpa.mil/program/translating-all-c-to-rust
AlotOfReading 2y ago
There's been a number of reports released by the government that recommend adopting memory safe languages as opposed to C/C++. The White House put out a memo [0] for example, and NIST has this page [1]. Since there are no other systems languages with widespread developer mindshare, some people see these as primarily recommending Rust. [0] https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/memory-safety-statements-of-support/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/mem... [1] https://www.nist.gov/itl/ssd/software-quality-group/safer-languages https://www.nist.gov/itl/ssd/software-quality-group/safer-la...
- jimbob45 2y ago
  What about MISRA C and C++ with static analysis tools? Also all GC languages would pretty easily solve the problem including Java and C#.
  - AlotOfReading 2y ago
    It's perfectly possible to write the crowdstrike issue in C/C++ code that will pass any MISRA checker, because MISRA checkers are unable to verify conformance with the standard. It basically says "don't do this" and leaves it up to the developer to ensure. Static analysis tools (broadly) are not powerful enough to ensure memory safety for nontrivial programs without a high developer burden in the form of annotations or restricted language subsets. GC languages are generally not appropriate for kernel level systems programming like crowdstrike was doing. Java has some history in this space, but generally without niceties like garbage collection that typical developers are used to.
- echelon 2y ago
  > some people see these as primarily recommending Rust. That's not the reason. The DoD really is focused on Rust [1, 2]. [1] https://www.darpa.mil/program/translating-all-c-to-rust https://www.darpa.mil/program/translating-all-c-to-rust [2] https://www.darpa.mil/news-events/2024-07-31a https://www.darpa.mil/news-events/2024-07-31a
  - AlotOfReading 2y ago
    The federal government is a lot bigger than even the DoD, and the other agencies (e.g. NIST as linked above) have been very careful to make sure they aren't only recommending Rust, even if it's clearly a major alternative.
notarealllama 2y ago
If you follow CISA vulns and guidelines, it's all industrial controllers getting hacked and pushing for memory safety for like a year straight. (On a side note, pleasantly surprised to see a Linux kernel android bug today)
keithalewis 2y ago
We're from the Government and we're here to help. You need a license to operate a backhoe, but not to write software.

AdieuToLogic 2y ago

> There is no reason to not use Rust for these systems anymore. While Rust is a fine language, there are others which may be better suited for systems which have a global impact such as CrowdStrike does. Ada: https://en.wikipedia.org/wiki/Ada_(programming_language) https://en.wikipedia.org/wiki/Ada_(programming_language) SPARK: https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) I am an advocate for neither and only reference their applicability for this problem domain based on the languages' design intent.

MaulingMonkey 2y ago

>> According to the RCA, the essence of what happened was an index out of bounds While Rust's behavior of panicing is saner than C++'s behavior of undefined behavior for a typical index out of bounds bug (`slice[index]`), I would imagine it'd still result in BSODs and outages in a kernel context. Admittedly, safe bounds checking (`slice.get(index) → Option<T>`) might be easier in Rust than in C++, but it's not a given that a RIIR would've avoided this bug.

MBCook 2y ago

Oh who cares about Rust. This could have been written in many different languages safely, including C/C++. Would it have been easier in Rust? Maybe. But it's also a legacy codebase. So we shouldn't be surprised it wasn't in Rust. There are SO MANY things that went wrong. They don't even seem to care about half of them. Ok, it wasn't tested. It wasn't staged. It wasn't a slow roll-out over hours. It wasn't verified from the deployment servers. How about why is it parsed in kernel space at all? I didn't see that listed. Why didn't you have a mechanism to catch faulty updates at runtime and flag them so that you'd be able to survive the next boot? Mark somewhere on the FS "I'm loading #19583". If you boot up and find that, it means you failed, so skip it next boot. Succeed? Remove the mark. Tada. Resiliency. Why are you even doing this stuff yourself? There are Microsoft APIs for a bunch of this stuff that would have helped reduce risk. Oh, because your code is deployed on XP and up and you don't want to have 2 or 3 versions? That went well didn't it. I bet if you were using those you wouldn't have crashed the kernel space. Do you fuzz? We know you don't. You broke Windows. You broke Macs. You broke Linux. You keep doing this. You're not good at being resilient. You had to face-plant in front of the entire world before you decided to do something. I didn't see fuzzing mentioned. Those mitigations you propose are not enough. They'll help, but you're still vulnerable. You're supposed to be a _security company_, I'd expect a better list of how to secure software from a security company. By all means, use Rust or Swift or (insert other memory safe language) if you want. That's smart. But if their existing kernel module had no UB and buffer overruns, it would still be doing things a kernel module shouldn't. The language involved is just a very tiny part.

aeyes 2y ago
> Oh, because your code is deployed on XP and up Not even, it only runs on 7 / 2008 Server and up.
jiggawatts 2y ago
> ...it means you failed, so skip it next boot. Succeed? Remove the mark. Tada. Resiliency. Better yet, it's high time that PCs booted like (some) mobile phones do: there's two copies of the OS. The running copy is read-only. The other copy can only be replaced with a monolithic "image" that has is validated with a HS256-based digitally signed Merkle hash. Either the entire image is bit-for-bit valid, or it is rejected. If booting to the new image fails twice, automatically roll back to the previous known-good image. This isn't "hard", it isn't even that much work. Heck, Windows can already boot from WIM images and VHDX disk images! The code is already in there, it just needs to be turned on.

jki275 2y ago

Rust isn't a panacea, and the US Government really isn't pushing for Rust adoption.