4 ms·

Well, we live in a world where we allow this kind of things to happen. Imagine if we live in a world where you still have to manually push and pop the stack (be

Well, we live in a world where we allow this kind of things to happen. Imagine if we live in a world where you still have to manually push and pop the stack (because functions are deemed too academic and not optimized exactly the way I want it). That is what I feels like watching critical infrastructures written in C or these older languages. Having to manually push and pop stack is not something to proud of, only do that out of necessity. There's a very reasonable option between C or C++ and Python (or whatever is deemed slow). Using C doesn't prevent you from designing a shitty application that uses shitty algorithms. "Ooohhhh I get it, this pointer is no longer valid because the array have been reallocated because that function have this side effect after that commit", he said as he gave out a small smirk at the hilarity of this bug. I wonder if he would find it as amusing if his coworker regularly rolls his sleeves and randomly regularly writes assemblies directly in the source code because compilers aren't smart enough to perform a particular parameter passing optimization that he really loves to do.

MaxBarraclough 2y ago
The US government agrees with you than unnecessary use of very unsafe languages is a serious cybersecurity problem. [0][1] A slight aside: Rust is typically held up as the obvious safer alternative to C/C++, as if Ada never existed. [0] https://stackoverflow.blog/2024/03/04/in-rust-we-trust-white-house-office-urges-memory-safety/ https://stackoverflow.blog/2024/03/04/in-rust-we-trust-white... [1] https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227
- anon-3988 2y ago
  I love Rust, but Rust is not particularly good either because "panics" are accepted in the Rust community.
  - tazjin 2y ago
    Panics are safe though (they're a controlled crash). The safety we're discussing is not related to program stability.
    - uecker 2y ago
      The problem here was that the kernel process got a fault, so a panic wouldn't have made a difference.
    - bdd8f1df777b 2y ago
      This incident, the blue screen of death, is exactly the same as a panic.
    - rabite 2y ago
      > Panics are safe though (they're a controlled crash). Here's Linus's commentary on that: https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099 > I think that if some Rust allocation can cause a panic, this is simply _fundamentally_ not acceptable. > Allocation failures in a driver or non-core code - and that is by definition all of any new Rust code - can never EVER validly cause panics. Panics are not acceptable in countless contexts. Plenty of things need to be written to keep working through entire categories of errors. The casual attitude of Rust developers towards error handling is one of the many reasons people have trouble taking it seriously. Reliability and robustness is generally more important than language memory safety for almost all contexts.
      - zahllos 2y ago
        There are indeed many cases where errors need to be recovered from and the subject of one angle in secure rust code training was quite literally "don't just panic, don't blindly unwrap or leave errors unhandled because that'll kill your thread/process on failure, you should still code for failure cases". If you do, you are coding denial of service bugs. But, in the incident in question, the code is fundamentally not correct. Spatial memory safety violations, or in plain English "trying to call functions or use data that isn't at addresses your code or data lives at" fundamentally is an error. There's a missing part of the state machine to detect and stop before just exploding. In userspace this is a segfault and your process dies. In kernel, you get a bugcheck and the whole system reboots. There are scary alternatives. The first, in kernel, is that you suppress all invalid writes and allow the errant code to keep writing, until it hits some other data. The system stays up, but you have out of control data writes so who knows what that's doing. The second is that the execution flow of the process can be hijacked, i.e. Sergey Bratus' weird machines, or in plainer language, owning kernels in critical infrastructure. This is usually undesirable.
- tomohawk 2y ago
  I recall Ada being strongly pushed, but at the time you needed a top of the line workstation ($60K - 100K in early 1990s dollars) and the per seat license for the compiler and other tooling was another $100K. And that was aside from the much longer/harder path to getting to a solution. We had two teams implement a system - one in C and one in Ada. The teams didn't know they were in competition with one another, but the much less experienced C team completed their solution so much faster than the Ada team, that they just dropped the Ada effort as unrealistic for use outside of specialized aerospace.
  - MaxBarraclough 2y ago
    I agree that the late arrival of a serious Free and Open Source Ada compiler did tremendous damage to Ada's adoption. I still think it reflects poorly on the software development community that Ada has been almost completely ignored despite that obstacle having been resolved decades ago. > The teams didn't know they were in competition with one another, but the much less experienced C team completed their solution so much faster than the Ada team, that they just dropped the Ada effort I realise you've given an abbreviated account, but it implies that: 1. No regard was paid to the relative quality of the 2 solutions 2. They ignored that initial development effort tends to be outweighed by ongoing development and maintenance 3. Many programmers are already familiar with C but not with Ada
uecker 2y ago
Some of the most reliable software I use is written in C. Software I use for decades and which never crashed for me. I can't say this about much other software. Clearly, you can write shitty software and this is also far too easy in C, but there are also many tools and techniques one can use to write reliable software in C. Rust is also a tool that can be used to write more reliable software, but it is not clear to me why this should suddenly make the big difference. People who want to write bad software can also sprinkle "unsafe" everywhere, and I would guess that this one happens a lot more once Rust is adopted more. And in the CrowdStrike case, Rust's default behavior to panic might not have necessarily prevented the problem. Having said this, regarding security against malicious hacking, memory safety is indeed one important component and Rust clearly has an edge there. In terms of general software bugs, it switching to other languages than C/C++ is certainly not a magic bullet and I often doubt that it would even an improvement in most scenarios.
- anon-3988 2y ago
  > Some of the most reliable software I use is written in C. Software I use for decades and which never crashed for me. I can't say this about much other software. After several years of efforts. I have written several apps in JavaScript, Rust, C++, Python. Of these, only Rust is the one that I can safely NEVER look back and be satisfied. Everything else just left me wondering if I have missed an enum or something stupid like that. > People who want to write bad software can also sprinkle "unsafe" everywhere, and I would guess that this one happens a lot more once Rust is adopted more. People actually _dont_ like to use unsafe (some people do, surprise, surprise, they are usually C folks). Most people that I see usually wants to get as quickly as possible out of unsafe. Why not? Believe it or not, people actually don't want to deal with tagged enums, or parse JSON themselves, or care about how do i properly set up SIMDs. They just use correct APIs so they can sleep at night instead of staring at stack traces. Rust is not perfect, true, but it is way, way better than C. How many software have been written in other language, and then the authors decided to write it back in C? If this does happen, it is usually something that is very well defined already. I haven't heard anything significant recently. I think there's a place in C as it provides a very stable and reliable API. > switching to other languages than C/C++ is certainly not a magic bullet its definitely a magic bullet that kills a LOT of problems tho? No one is saying it fixes everything. If we keep using C or C++ for the next 1000 years, we will have the same sets of problems. Things will NEVER improve.

MaxBarraclough 2y ago

The US government agrees with you than unnecessary use of very unsafe languages is a serious cybersecurity problem. [0][1] A slight aside: Rust is typically held up as the obvious safer alternative to C/C++, as if Ada never existed. [0] https://stackoverflow.blog/2024/03/04/in-rust-we-trust-white-house-office-urges-memory-safety/ https://stackoverflow.blog/2024/03/04/in-rust-we-trust-white... [1] https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227

anon-3988 2y ago
I love Rust, but Rust is not particularly good either because "panics" are accepted in the Rust community.
- tazjin 2y ago
  Panics are safe though (they're a controlled crash). The safety we're discussing is not related to program stability.
  - uecker 2y ago
    The problem here was that the kernel process got a fault, so a panic wouldn't have made a difference.
  - bdd8f1df777b 2y ago
    This incident, the blue screen of death, is exactly the same as a panic.
  - rabite 2y ago
    > Panics are safe though (they're a controlled crash). Here's Linus's commentary on that: https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099 > I think that if some Rust allocation can cause a panic, this is simply _fundamentally_ not acceptable. > Allocation failures in a driver or non-core code - and that is by definition all of any new Rust code - can never EVER validly cause panics. Panics are not acceptable in countless contexts. Plenty of things need to be written to keep working through entire categories of errors. The casual attitude of Rust developers towards error handling is one of the many reasons people have trouble taking it seriously. Reliability and robustness is generally more important than language memory safety for almost all contexts.
    - zahllos 2y ago
      There are indeed many cases where errors need to be recovered from and the subject of one angle in secure rust code training was quite literally "don't just panic, don't blindly unwrap or leave errors unhandled because that'll kill your thread/process on failure, you should still code for failure cases". If you do, you are coding denial of service bugs. But, in the incident in question, the code is fundamentally not correct. Spatial memory safety violations, or in plain English "trying to call functions or use data that isn't at addresses your code or data lives at" fundamentally is an error. There's a missing part of the state machine to detect and stop before just exploding. In userspace this is a segfault and your process dies. In kernel, you get a bugcheck and the whole system reboots. There are scary alternatives. The first, in kernel, is that you suppress all invalid writes and allow the errant code to keep writing, until it hits some other data. The system stays up, but you have out of control data writes so who knows what that's doing. The second is that the execution flow of the process can be hijacked, i.e. Sergey Bratus' weird machines, or in plainer language, owning kernels in critical infrastructure. This is usually undesirable.
tomohawk 2y ago
I recall Ada being strongly pushed, but at the time you needed a top of the line workstation ($60K - 100K in early 1990s dollars) and the per seat license for the compiler and other tooling was another $100K. And that was aside from the much longer/harder path to getting to a solution. We had two teams implement a system - one in C and one in Ada. The teams didn't know they were in competition with one another, but the much less experienced C team completed their solution so much faster than the Ada team, that they just dropped the Ada effort as unrealistic for use outside of specialized aerospace.
- MaxBarraclough 2y ago
  I agree that the late arrival of a serious Free and Open Source Ada compiler did tremendous damage to Ada's adoption. I still think it reflects poorly on the software development community that Ada has been almost completely ignored despite that obstacle having been resolved decades ago. > The teams didn't know they were in competition with one another, but the much less experienced C team completed their solution so much faster than the Ada team, that they just dropped the Ada effort I realise you've given an abbreviated account, but it implies that: 1. No regard was paid to the relative quality of the 2 solutions 2. They ignored that initial development effort tends to be outweighed by ongoing development and maintenance 3. Many programmers are already familiar with C but not with Ada

uecker 2y ago

Some of the most reliable software I use is written in C. Software I use for decades and which never crashed for me. I can't say this about much other software. Clearly, you can write shitty software and this is also far too easy in C, but there are also many tools and techniques one can use to write reliable software in C. Rust is also a tool that can be used to write more reliable software, but it is not clear to me why this should suddenly make the big difference. People who want to write bad software can also sprinkle "unsafe" everywhere, and I would guess that this one happens a lot more once Rust is adopted more. And in the CrowdStrike case, Rust's default behavior to panic might not have necessarily prevented the problem. Having said this, regarding security against malicious hacking, memory safety is indeed one important component and Rust clearly has an edge there. In terms of general software bugs, it switching to other languages than C/C++ is certainly not a magic bullet and I often doubt that it would even an improvement in most scenarios.

anon-3988 2y ago
> Some of the most reliable software I use is written in C. Software I use for decades and which never crashed for me. I can't say this about much other software. After several years of efforts. I have written several apps in JavaScript, Rust, C++, Python. Of these, only Rust is the one that I can safely NEVER look back and be satisfied. Everything else just left me wondering if I have missed an enum or something stupid like that. > People who want to write bad software can also sprinkle "unsafe" everywhere, and I would guess that this one happens a lot more once Rust is adopted more. People actually _dont_ like to use unsafe (some people do, surprise, surprise, they are usually C folks). Most people that I see usually wants to get as quickly as possible out of unsafe. Why not? Believe it or not, people actually don't want to deal with tagged enums, or parse JSON themselves, or care about how do i properly set up SIMDs. They just use correct APIs so they can sleep at night instead of staring at stack traces. Rust is not perfect, true, but it is way, way better than C. How many software have been written in other language, and then the authors decided to write it back in C? If this does happen, it is usually something that is very well defined already. I haven't heard anything significant recently. I think there's a place in C as it provides a very stable and reliable API. > switching to other languages than C/C++ is certainly not a magic bullet its definitely a magic bullet that kills a LOT of problems tho? No one is saying it fixes everything. If we keep using C or C++ for the next 1000 years, we will have the same sets of problems. Things will NEVER improve.