Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk • Hacker News Board

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

#81

Post by sunshowers » Fri, Nov 01, 2024, 9:34 PM UTC

aithrowawaycomm wrote: post #53

This seems somewhat incoherent and is too focused on shallow claims about languages instead of trying to understand why the memory bugs happened in the first place. Are unsafe code blocks in Rust or C# okay? Presumably yes if there are good reasons to do so, sometimes it is necessary. But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are su…

> To be clear this isn't a criticism of Rust's design or implementation - demarcated blocks of unsafe code is pragmatic and sensible. The problem is how humans build software. In this sense I don't think we've really settled whether "rewrite the code in Rust" is actually safer than "redo our technical management to include automated memcheck testing and paired code reviews." At the very least, I don't think the latter is insufficient

I think the latter is woefully insufficient, having seen critical C++ memory safety bugs that got past every sanitizer. For me the debate was settled once our team at Meta shipped a large, high-performance Rust service, built over many years, that simply did not have memory safety bugs -- and its success became a crucial part of why Rust is now a first-class language at Meta.

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

#82

Post by cryptonector » Sat, Nov 02, 2024, 4:56 AM UTC

Animats wrote: post #78

cryptonector wrote: post #77

Earlier quoted context omitted.

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

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

Well, yeah, that's a problem.

But the bigger problem is that this works for jets, as long as you don't need updates. It doesn't work for general purpose computers, for office productivity software, for databases (is there an RDBMS with a correctness proof?), etc. It's not that one couldn't build such things, it's that the cost would be absolutely prohibitive.

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

#83

Post by EasyMark » Sat, Nov 02, 2024, 4:01 PM UTC

pointlessone wrote: post #65

EasyMark wrote: post #61

Earlier quoted context omitted.

While these types of failures are the 50-70% problem, 30% left seems like a big problem too and the black-hats will just concentrate more on those if the low hanging fruit are removed with rust, C#, python, whatever

50-70% defect reduction is significant, though. It is true that black hats are going to focus on the remainder pretty much by definition because there’s no other choice. The rest is a problem and it needs a solution. But the fact that it exists is not a sound argument against choosing a memory-safe language. Current solutions are not ideal but they still eliminate a huge portion of defects. Today we can avoid all the…

I guess my point was it won’t be a “tidal wave” of solved security issues. No all the effort that went into find buffer overflow and use after free errors just gets shifted to combing through code for logic errors and missed opportunities to tighten up checks. It’s not going to be 50-70% reduction. Maybe half that? I mean it would help, but it’s not going to fix the problem in a huge way at all.

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

#84

Post by EasyMark » Sat, Nov 02, 2024, 4:02 PM UTC

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…

Ooooo thanks for the rare gem of comment to give me fun things to look up.

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

#85

Post by jrpelkonen » Sat, Nov 02, 2024, 7:04 PM UTC

jandrewrogers wrote: post #40

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 think it is important to recognize that this will only apply to generic normal software, which is already mostly written in memory-safe languages for government e.g. Java. Data infrastructure with state-of-the-art scale, performance, and workload requirements will continue to be written in C++ for the foreseeable future, largely because there is no alternative. Maybe Zig some day? A pattern I’ve seen (and used myse…

Calling Rust a "better Java" and not a credible alternative for C++ for "extreme systems software" without further detail is an opinion that I find hard to take seriously. So I'd like to understand your viewpoint better. Could you elaborate on what aspects in C++ specifically make it so much better suited for these tasks from performance and maintainability perspective?

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

#86

Post by Animats » Sat, Nov 02, 2024, 8:41 PM UTC

cryptonector wrote: post #82

Animats wrote: post #78

Earlier quoted context omitted.

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…

> 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. Well, yeah, that's a problem. But the bigger problem is that this works for jets, as long as you don't need updates. It doesn't work for general purpose computers, for office productivity software, for databases (is there an RDBMS with a correctness proof?), etc. It's…

It's not for everything. But the serious verification techniques should be mandatory in critical infrastructure. Routers, BGP nodes, and firewalls would be a good place to start. Embedded systems that control important things - train control, power distribution, pipelines, water and sewer. Get those nailed down hard.

Diagrams like this scare me.[1]

[1] https://new.abb.com/docs/librariesprovider78/eventos/jjtts-2...

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

#87

Post by cryptonector » Sat, Nov 02, 2024, 10:15 PM UTC

Animats wrote: post #86

cryptonector wrote: post #82

Earlier quoted context omitted.

> 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. Well, yeah, that's a problem. But the bigger problem is that this works for jets, as long as you don't need updates. It doesn't work for general purpose computers, for office productivity software, for databases (is there an RDBMS with a correctness proof?), etc. It's…

It's not for everything. But the serious verification techniques should be mandatory in critical infrastructure. Routers, BGP nodes, and firewalls would be a good place to start. Embedded systems that control important things - train control, power distribution, pipelines, water and sewer. Get those nailed down hard. Diagrams like this scare me.[1] [1] https://new.abb.com/docs/librariesprovider78/eventos/jjtts-2...

> Routers, BGP, ...

Well, but those need new features from time to time, and certification would make that nigh impossible. I'd settle for memory-safe languages as the happy middle of the road.

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

#88

Post by timClicks » Sun, Nov 03, 2024, 3:02 AM UTC

nanolith wrote: post #42

Leave it to politicians to pit bull a language. Model checked C/C++ is memory safe. Had they reached out to a wider set of people for guidance, they'd have a more balanced report. I will agree that software safety -- not just memory safety -- is critical. Trying to attack this at the language level instead of the development process and assurance level is daft. FIPS certification and aerospace certification both requ…

That's the intent of the document - to reach people for guidance. The document under discussion is requesting comment from industry.

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

#89

Post by microkerneldude » Sun, Nov 03, 2024, 7:11 AM UTC

cryptonector wrote: post #82

Animats wrote: post #78

Earlier quoted context omitted.

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…

> 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. Well, yeah, that's a problem. But the bigger problem is that this works for jets, as long as you don't need updates. It doesn't work for general purpose computers, for office productivity software, for databases (is there an RDBMS with a correctness proof?), etc. It's…

seL4 is a bit more than a hypervisor, but it's definitely very low-level. In terms of a useful seL4-based system, you may want to look at https://trustworthy.systems/projects/LionsOS/ – not yet verified, but will be.

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

#90

Post by tetnis » Sun, Nov 03, 2024, 5:22 PM UTC

sunshowers wrote: post #80

tetnis wrote: post #79

Earlier quoted context omitted.

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?

Ok, I didn't really define logic bugs. I think of things like race conditions as memory bugs because its improper access to the same variable.

So I suppose All Bugs Are Logic Bugs.

But I really meant that many software software vuln aren't even that fancy. Sure if you have something like an iPhone which has whole companies trying to hack it, then eventually the bugs you have left are fancy heap overflows. But lots of products have logic errors, like mischecking creds etc.

I will also pick on CISA for recommending a language that requires something like cargo. Why is it a good idea for critical infrastructure to require internet access to compile its code? CISA is supposed to be concerned about the fact that critical infra. is privately held and they should encourage secure practices. So suggest a language that in practice requires internet access? this is absurd to me.