Comment by anon-3988 | Hacker News Reader

Comment by anon-3988 | Hacker News Reader

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.

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

[1] https://news.ycombinator.com/item?id=33560227

I love Rust, but Rust is not particularly good either because "panics" are accepted in the Rust community.

Panics are safe though (they're a controlled crash). The safety we're discussing is not related to program stability.

The problem here was that the kernel process got a fault, so a panic wouldn't have made a difference.

This incident, the blue screen of death, is exactly the same as a panic.

> Panics are safe though (they're a controlled crash).

Here's Linus's commentary on that:

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.

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.

Panics are only safe if you have an OS to catch you. They are definitely not safe in the CS context.

Panics in a user-space application are likely safe and the correct thing to do.

Panics in a real-time system or a kernel are quite possibly not.

In a hospital system nobody cares whether it was the kernel or the application that caused people to die.

A blue screen of death as caused in this case is also a controlled crash, in fact. The processor has fired an interrupt indicating invalid memory access and piece of windows code does some emergency logic, namely, dump memory so you can maybe diagnose it later, and reboot.

The reboot part happens because the system is assumed to be in a bad state and allowing it to continue would possibly corrupt data, or in the worst possible case execute exploit code.

This panic handler runs in the same privilege as the faulty driver and can itself be prevented from running correctly. Notably file system drivers are required to function correctly to write the memory dump. If they, or filter drivers attached to them, also fault, well, fun times.

You can have faults in an interrupt handler too, for example trying to access paged memory in a page fault handler. That'll trigger a double fault handler and if you fault in that, the processor will perform a reset and not bother even notifying software. Luckily the double fault handlers and other such cases are usually solely the preserve of OS vendors.

I have no particular point except to illumate what's going on and that processors (in this case x86 terminology is used) and that actually recognizing and aborting from an invalid state is exactly what's happening here and what rust memory safety does. In spite of the disruption that's better than silently corrupting data.

Forgive my ignorance, but to your last point about Rust aborting an invalid state… Isn’t Rust considered more memory safe because it catches many mistakes at compile time and not runtime?

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.

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

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.

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

This is a lot "in my opinion better or worse". I disagree.

And yes, it happens that stuff is written in C. But it is not discussed every time on HN such as the many "XY written in Rust" articles, because the the later apparently is still newsworthy.

Reply on news.ycombinator.com