this post was submitted on 10 Nov 2024

205 points (92.9% liked)

Programming

17408 readers

76 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 [email protected]

founded 1 year ago

MODERATORS

[email protected]

205

The US government wants devs to stop using C and C++ (www.theregister.com)

submitted 4 days ago by [email protected] to c/[email protected]

79 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 77 points 4 days ago (2 children)

But there is context to it:

The report on Product Security Bad Practices warns software manufacturers about developing "new product lines for use in **service of critical infrastructure or [national critical functions] **NCFs in a memory-unsafe language (eg, 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."

It's for new products that are very important to critical infrastructure and need to be safe as possible. The article writer seem not to be aware of this context:

Take Rust in Linux, for example. Even with support from Linux's creator, Linus Torvalds, Rust is moving into Linux at a snail's pace.

Because Linux is the biggest software in the entire world and they do lot of stuff their own way. Rust is integrated slowly for future new projects. It makes sense to move in snail pace. The government doesn't suggest the Linux project to stop using C entirely. The government "recommends" to start new projects in memory safe languages, if it is a critical software. That makes sense to me.

You see, people who've spent years and sometimes decades mastering C don't want to master the very different Rust. They don't see the point.

No, totally wrong. C programmers in Linux do not NEED to learn or master Rust. They just need to cooperate. The problem is, that some C programmers refuse to cooperate with Rust. They just want Rust to disappear. That has nothing to do with mastering the language. They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

After all, they can write memory-safe code in C, so why can't you?

Nonsense argument, and false too. If that was the case, why do we have memory safe languages? Clearly people make mistake, old and new. Besides Linux is not the only software in the world.

Converting existing large codebases to memory-safe languages can be an enormous undertaking.

Nobody says old code should be rewritten in Rust. Neither the government, nor the Rust programmers in Linux suggest that. It's not about rewriting code in memory-safe languages, its about new projects.

Either this article is a misrepresentation or misunderstanding. Or I misunderstand the article or government. I don't know anymore...

[–] [email protected] 34 points 4 days ago (1 children)

They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

I don't even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.

[+] [email protected] -6 points 4 days ago (3 children)

The Rust kernel devs are ...

...asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.
...asking maintainers to accept code into their subsystem whilst being told, you don't need to know Rust to an expert level...trust us. Cross language interfaces always have nuance and make good attack vectors. Understandable that maintainers are cautious.
...creating quite a lot of hassle for no a lot of improvement. Systems are only as resilient as their weakest components. The cross language interface is always going to be weak. Introducing a weakness to get improvements probably only succeeds at making the whole weaker.

[–] [email protected] 27 points 3 days ago

asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.

No, they were asking them to define the semantics of the filesystem APIs. Those semantics are not encoded in the C API but the Rust devs wanted to encode them in the Rust API to avoid making mistakes.

The C devs didn't want to, not because of concerns about binary drivers, but because the semantics are already broken. Apparently different filesystem drivers assume different semantics for the same functions and it's a whole mess. They don't want to face up to this and certainly don't want anyone pointing it out, so clearly it must be the Rust devs' fault for wanting APIs to have consistent semantics.

The rest of your comment is nonsense.

[–] [email protected] 7 points 3 days ago (1 children)

What's the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don't quite understand what it even is about

[–] [email protected] 14 points 3 days ago (1 children)

Having binary blobs linked into your kernel is a maintainability nightmare. You're allowing a third party to link their buggy drivers into the heart of your platform. It breaks any security model you have, and brings with a bunch of bugs that are impossible to debug.

Nvidia were the worst offender and it culminated in this:

https://arstechnica.com/information-technology/2012/06/linus-torvalds-says-f-k-you-to-nvidia/

[–] [email protected] 1 points 3 days ago (1 children)

Got it. I agree that their drivers are (were?) of exemplary bad quality

But I don't think that it is realistically possible to drop all the proprietary firmware blobs, and if it's not maybe it's better to not actively sabotage something to 'avoid those being feasible'?

[–] [email protected] 2 points 3 days ago

Firmware don't link to the kernel tho, and the kernel functions aren't stable so a firmware today would stop working tomorrow because a function was refactored(and all the code in the kernel that depend on that function) for performance or security, and the binary can't be refactored so it become useless

[–] [email protected] -3 points 3 days ago (1 children)

IIRC They were also trying to get kernel devs to let official structure definitions live in Rust instead of C, and got upset when they didn't want to do that.

[–] [email protected] 12 points 3 days ago

the rust devs wanted to CREATE official structure definitions that don’t exist in C so that there was more semantic meaning to the APIs

[–] [email protected] 7 points 3 days ago

No, totally wrong. C programmers in Linux do not NEED to learn or master Rust. They just need to cooperate. The problem is, that some C programmers refuse to cooperate with Rust. They just want Rust to disappear. That has nothing to do with mastering the language. They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

I would argue that's not the biggest problem, the biggest problem is that for you to refactor a function to work with rust, you need to refactor all the subsystems that rely on that function, and that take time, and you need to explain for the C dev why it need to be done, try to explain that for the amount of C devs in the kernel