this post was submitted on 01 Nov 2024

74 points (90.2% liked)

Programming

17389 readers

150 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk (thenewstack.io)

submitted 1 week ago by arendjr@programming.dev to c/programming@programming.dev

32 comments fedilink hide all child comments

all 33 comments

sorted by: hot top controversial new old

[–] sp3tr4l@lemmy.zip 61 points 1 week ago (3 children)

... Are the Feds aware that the core systems that many, many older companies (and government agencies) use are still based on COBOL?

Is... is that not of any concern?

[–] aubeynarf@lemmynsfw.com 22 points 1 week ago (1 children)

Is COBOL subject to buffer overflows and use-after-free bugs? I honestly don’t know.

I don’t recall the COBOL code I’ve read using pointers.

[–] sp3tr4l@lemmy.zip 13 points 1 week ago

The problem I am aware of is moreso that the number of programmers that know COBOL is vanishingly small, it ... COBOL does not seem to really be taught anymore...

...so if something goes wrong at that level, you may be SOL if you cannot find an increasingly rare programmer that knows COBOL well.

[–] tyler@programming.dev 5 points 1 week ago

The article says this isn’t to affect existing code.

[–] wewbull@feddit.uk 42 points 1 week ago (3 children)

That sounds like policy written by somebody who has no idea what the reality of software development is.

1 year to rewrite critical software in a new language?

[–] nous@programming.dev 79 points 1 week ago

Did you read the article at all?

“Putting all new code aside, fortunately, neither this document nor the U.S. government is calling for an immediate migration from C/C++ to Rust — as but one example,” he said. “CISA’s Secure by Design document recognizes that software maintainers simply cannot migrate their code bases en masse like that.”

Companies have until January 1, 2026, to create memory safety roadmaps.

All they are asking for by that date is a roadmap for dealing with memory safety issues, not rewrite everything.

[–] GetOffMyLan@programming.dev 24 points 1 week ago

That sounds like a comment written by somebody who has no idea what the article says

[–] IsThisAnAI@lemmy.world 1 points 1 week ago

Solid detective work Lou.

[–] mox@lemmy.sdf.org 25 points 1 week ago* (last edited 1 week ago)

Don't assume too much from the headline, folks. They're not saying everything has to be rewritten by 2026. They're saying new product lines serving critical infrastructure should be written in memory-safe languages, and existing ones should have a memory safety roadmap.

If you're about to post about how you think that's unreasonable, I think you should explain why.

[–] Sonotsugipaa@lemmy.dbzer0.com 12 points 1 week ago (1 children)

That is an extremely oddly specific cysec issue they're choosing to target...

[–] BlazeDaley@lemmy.world 20 points 1 week ago

It’s one backed by a lot of data. One example is from the Android project.

The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

There’s an argument that critical infrastructure software vendors are already meeting standards for basic, non-memory related items. Yes, there are other categories, but memory safety is one that’s harder to verify. Moving to memory safe languages is an ensure a category of correctness. This excludes usage of unsafe escape hatches.

[–] MyNameIsRichard@lemmy.ml 12 points 1 week ago* (last edited 1 week ago) (1 children)

Feds have found a way to hack rust /s?

[–] sp3tr4l@lemmy.zip 15 points 1 week ago (1 children)

DARPA has unironically been funding a tool that purports to translate C / C++ into Rust...

https://www.darpa.mil/program/translating-all-c-to-rust

[–] lud@lemm.ee 1 points 1 week ago

That's nice.

[–] perviouslyiner@lemmy.world 10 points 1 week ago* (last edited 1 week ago) (5 children)

Seems excessive to convert everything to rust when you can use std::shared_ptr and std::weak_ptr to eliminate the memory safety issue?

[–] arendjr@programming.dev 31 points 1 week ago* (last edited 1 week ago) (1 children)

Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

[+] refalo@programming.dev -10 points 1 week ago (2 children)

To be fair, it's entirely possible to make the same and very similar mistakes in Rust, too.

[–] GetOffMyLan@programming.dev 7 points 1 week ago* (last edited 1 week ago)

I'm fairly sure use after free isn't possible unless you explicitly use unsafe code right?

It's compiler enforced is the point.

[–] robinm@programming.dev 1 points 1 week ago (1 children)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

[–] refalo@programming.dev 0 points 1 week ago (1 children)

I think you could argue the same point with C++

[–] robinm@programming.dev 1 points 3 days ago (1 children)

void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

[–] refalo@programming.dev 1 points 3 days ago* (last edited 3 days ago) (2 children)

This would be caught by ASan and other tools though, which should be part of any review.

[–] robinm@programming.dev 0 points 17 hours ago

I think you have a hard time understanding the différence between "not possible" and "much harder".

In Rust, the code does not compile.

In C++ the code compile, but

if you have a test case
this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
you use ubsan

... then the bug will be caught.

Yes it is possible, noone says the opposite. But you can't deny it's harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The

[–] robinm@programming.dev 1 points 3 days ago

That's why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.

To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn't grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.

Asan is a wonderfull tool, but you can't deny it's much harder to use and much less reliable than just running your compiler.

[–] cmnybo@discuss.tchncs.de 16 points 1 week ago (1 children)

I wonder how many issues rewriting everything in another language will create?

[–] tyler@programming.dev 8 points 1 week ago

Just as many issues as not reading the article.

[–] psycotica0@lemmy.ca 12 points 1 week ago

I get what you're saying, but I think the issue with optional memory safety features is that it's hard to be sure you're using it in all the places and hard to maintain that when someone can add a new allocation in the future, etc. It's certainly doable, and maybe some static analysis tools out there can prove it's all okay.

Whereas with Rust, it's built from the ground up to prove exactly that, plus other things like no memory being shared between threads by accident etc. Rust makes it difficult and obvious to do the wrong thing, rather than that being the default.

[–] magic_lobster_party@fedia.io 8 points 1 week ago

From the original document:

Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026.

My interpretation is that smart pointers are allowed, as long it’s systematically enforced. Switching to a memory safe language is just one example.

[–] FizzyOrange@programming.dev 3 points 1 week ago

I have never seen a single C++ codebase do that. It helps but it's not a practical full solution.

[–] jia_tan@lemmy.blahaj.zone 6 points 1 week ago

🦀🦀🦀

[–] NauticalNoodle@lemmy.ml 3 points 1 week ago

is Rust ready for this?

[–] Primer81@lemmy.zip 2 points 1 week ago

Just from reading the article, is the scope just critical software infrastructure? What does that encompass exactly? Banking and military software seems easy to assume - what about embedded medical device software? Or just embedded software in general?