Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

thenewstack.io

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#71

Post by Ygg2 »

aithrowawaycomm wrote: post #57
erik_seaberg wrote: post #55

Earlier quoted context omitted.

Rust's borrow checker proves some invariants that the code always upholds. Valgrind only checks that this run hasn't triggered some undefined behavior so far, it's always possible that (ab)using it further or another run with different input might.

> But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective. I did not say they were the same or even equivalent, though I was sloppy with synecdoche and didn't specifically mean Valgrind. My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgrind, and the feds a…

> My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgind

Your point is wrong is the issue.

Doing unsafe Rust is harder – there is some syntaxic salt plus doing unsafe code in Rust requires different mindset.

But it's also safer. Why? Because borrow checker is never turned off. Plus you get warning, lints, miri, clippy warning about your code being wrong.

> It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors.

Again, wrong. It should go like this "Rewrite in Rust will be memory safe (assuming we didn't bungle up the unsafe bits)".

Compiler relies on you for checking the boundary between safe and unsafe. If that's correct, great. If not you only have to check like 5% of your codebase. Which is 20x less than 100%. Maybe I'm not a 20x developer.

Which is a stark contrast to C++ you either write your safe abstractions and pray to God that others won't break, or you make Vec.pop be unsafe because you can't be bothered to return an Optional or null.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#72

Post by nanolith »

rich_sasha wrote: post #64
nanolith wrote: post #50

Earlier quoted context omitted.

Yep. ESBMC and PolySpace both work for C++. I use CBMC for C. They run an abstract machine model through an SMT solver. Among other things, this abstract machine model tracks memory usage, UAF, aliasing, etc. With custom assertions, it can also cover issues like casting safety, serialization issues, logic errors, etc. More or less, you can build up any proof obligations you need and run them through the model checker…

How very interesting. Does that detect issues at runtime, or prove statically that the code is "safe" (whatever the remit of that definition is here)? If the former, I guess you're still at the mercy of test coverage and all the pitfalls it entails.

Model checking employs abstract interpretation, so it's similar to static analysis. I hesitate to use the latter term, because it's often used to describe how linting works. This is significantly more advanced.

The model checker translates an abstract model of execution for the code into an SMT solver, and uses this to find counter-examples. The SMT solver works backward from failure cases to discover a combination of inputs or program state that can cause any one of these failure cases. This traces memory, data flow, and control flow. It's actually a pretty neat thing.

It doesn't require existing test coverage or anything at runtime to work.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#73

Post by multimoon »

Veserv wrote: post #25

Cool. Is this going to require phasing out systems written in C/C++ with horrible security track records like Linux and Windows? Or are they going to get a "too critical to be improved" exemption?

This is the most HN comment I’ve seen in recent memory.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#74

Post by cryptonector »

generalizations wrote: post #33
Animats wrote: post #5

“The development of new product lines for use in service of critical infrastructure or [national critical functions] NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.” Now that's a strong statement.…

I wonder if this is a real solution. "Memory safety" has sure been pushed hard the last few years, but this feels more like a "we need to do something, this is something, we should do this" kind of response than anything that will really address the issue. If security-through-virtualization had been the fad lately, would that have been proposed instead?

It's a 90% solution, not a 100% solution. We don't have a 100% solution, not at any affordable cost.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#75

Post by cryptonector »

Veserv wrote: post #48
generalizations wrote: post #33

Earlier quoted context omitted.

I wonder if this is a real solution. "Memory safety" has sure been pushed hard the last few years, but this feels more like a "we need to do something, this is something, we should do this" kind of response than anything that will really address the issue. If security-through-virtualization had been the fad lately, would that have been proposed instead?

It is not a real solution. The people delivering memory-safe code today do not think their systems are secure against individual, lone attackers, let alone fully-funded state actors. The overwhelming majority of them, all software developers, and software security professionals probably think it is literally impossible to design and develop usable systems secure against such threats, i.e. can achieve the desired requ…

I think certification overestimates security, absolutely. Certification proves nothing.

You can use theorem provers to prove correctness, but you can't prove that the business logic is correct. There's a degree to which you just cannot prevent security vulnerabilities.

But switching to memory-safe languages will reduce vulnerabilities by 90%. That's not nothing.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#76

Post by gigel82 »

gigel82 wrote: post #4

C++ is only "memory-unsafe" if you are hiring bottom of the barrel talent. Likely the same kind of folks for which we had to change car manuals from including schematics and repair instructions to including warnings about not drinking the coolant...

Hate that all you want, but you know it's true if you've been in the industry for more than a couple of years.

It's a mistake to cater to the lowest common denominator. We'll all be coding in Scratch in a decade if we keep down this path.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#77

Post by cryptonector »

Animats wrote: post #66
Veserv wrote: post #48

Earlier quoted context omitted.

It is not a real solution. The people delivering memory-safe code today do not think their systems are secure against individual, lone attackers, let alone fully-funded state actors. The overwhelming majority of them, all software developers, and software security professionals probably think it is literally impossible to design and develop usable systems secure against such threats, i.e. can achieve the desired requ…

> f you actually want to be secure against state actors, you need to start from things that work, or at least things that people believe could, in principle, work and then work down. Historically, there were systems certified according to the TCSEC Orange Book that, ostensibly, the DoD at the time, 80s to 90s, believed were secure against state actors. A slightly more modern example would be the Common Criteria SKPP…

> That is extremely expensive.

And it proves nothing. And it's as expensive for every update, so forget updates.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#78

Post by Animats »

cryptonector wrote: post #77
Animats wrote: post #66

Earlier quoted context omitted.

> f you actually want to be secure against state actors, you need to start from things that work, or at least things that people believe could, in principle, work and then work down. Historically, there were systems certified according to the TCSEC Orange Book that, ostensibly, the DoD at the time, 80s to 90s, believed were secure against state actors. A slightly more modern example would be the Common Criteria SKPP…

> That is extremely expensive. And it proves nothing. And it's as expensive for every update, so forget updates.

Provenrun, used in military aircraft, has 100% formal proof coverage on the microkernel.

We know how to approach this. You use a brutally simple microkernel such as SEL4 and do full proofs of correctness on it. There's a performance penalty for microkernels, maybe 20%, because there's more copying. There's a huge cost to making modifications, so modifications are rare.

The trouble with SEL4 is that it's not much more than a hypervisor. People tend to run Linux on top of it, which loses most of the security benefits.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#80

Post by sunshowers »

tetnis wrote: post #79
tetnis wrote: post #31

CISA is stupid. Logic bugs don't go away with Rust.

People can downvote all they want. But CISA needs a talking point, and "Rust solves it" is one they won't ever let go. Go talk to those freaks and remember I told you so.

I regularly solve logic bugs using affine typing and shared xor mutability, so clearly some subset of logic bugs is solved with Rust, no?
Post reply on HN