Memory safety for the world’s largest software project | Hacker News Reader

Memory safety for the world’s largest software project

memorysafety.org

110 pointscodewiz58 comments

I’m so excited for this project. I feel like this is going to bring in a new generation of programmers to kernel development.

When GCC support [0] lands it's going to be a complete game-changer.

[0] https://github.com/rust-lang/rustc_codegen_gcc

I think the GCC Front-End For Rust [1] is going to have an even larger impact going forward.

[1]: https://github.com/Rust-GCC/gccrs

So, when Rust is actually in the kernel would it be possible for some C based routines to call them? Like the article seems to mention things I've seen as "helper" functions, so a mostly C module can get some memory safe benefits? Or do whole components need to be rewritten?

Theoretically yes, rust binaries can have C-apis and other code can call them just fine.

With the caveat that, naturally, these APIs can only expose concepts that C can understand, so you're a bit limited. No generics, for example.

Also, no memory safety...

Well its the C coding calling the Rust that has no memory safety, the rust code exposed as the C binary will (assuming no unsafe block) be memory safe, despite appearing to C like other C code.

Yep! At our company, for example, we have built a plugin for PAM in Rust which exposes all the necessary functions with a C interface.

This sounds really interesting! Is the source available somewhere?

The RUST FFI is just the C function interface. You can completely fool the C code that you are also C code.

Not only is it possible, being able to do so well is a design constraint on the language.

Question regarding licensing: [1] states that a source file can be "one of the compatible GPL variants and alternatively under a permissive license like BSD, MIT etc."

Looking at a rust source file inside the dev tree 'Rust-for-Linux' [2], it is licensed as "Apache-2.0 OR MIT". However, Apache-2.0 appears to be incompatible with GPL-2.0 [3]. How come that the licensing in such a way is possible with the Linux licensing rules?

[1] https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://github.com/Rust-for-Linux/linux/blob/rust/rust/alloc... [3] https://opensource.stackexchange.com/questions/1357/can-i-li...

Edit: Another quote from [1]: "[...], though individual source files can have a different license which is required to be compatible with the GPL-2.0:"

With alternatives like that, you choose what applies, so if it's licensed as "MIT or literally-anything-else", it's still valid. Now why they chose to add Apache2, that is interesting.

A guess: if contributions to the project also need to be mit-or-asl2, then maybe that would force the patent grant clause to apply for contributions? (even if it doesn't change anything for the users)

The core Rust project (and consequently much of the ecosystem) is dual-licensed MIT or Apache-2.0, so it's not at all surprising to see that continue here.

Ah, I see, thanks. Somehow I hadn't looked at GPL-2.0 compatibility of the MIT license, which would have answered the question.

Can we talk about “world’s largest”? This seems extremely unlikely by any measure.

kinda feel like the title is earned. Linux (to my knowledge) is the most used operating system in the world and runs on all of the top 500 fastest super computers.

MINIX also makes that claim by virtue of running on the Intel ME.

What do you think is a larger software project? Could argue for SQLite being deployed more widely. But it's hardly even 1% of the overall code surface of the Linux kernel.

Android? They need to develop "repo" tool to use git. Similarly, Windows should be bigger (though it's closed source) so they develop VFSforGit tool.

Android runs a linux kernel under the hood, so it seems hard to make the argument that it is a bigger software project.

As for windows, I'm fairly certain that more devices run the linux kernel than Windows as well.

I think "Largest" is for codebase size. For most widespread software project, it would be SQLite or Zlib.

What about by number of contributors?

Looks good metric than how it widespread.

Going by lines of code, Linux is probably not the largest: https://www.informationisbeautiful.net/visualizations/millio...

Linux currently has around 30 million lines of code I believe.

Possibly the largest open source software project? I know it says Open Office is bigger but it seems like Linux has grown since then.

Surprised the 5ESS wasn't mentioned on here: https://en.wikipedia.org/wiki/5ESS_Switching_System

> The development effort for 5ESS required five thousand employees, producing 100 million lines of system source code, mostly in the C language, with 100 million lines of header files and makefiles.

Granted, this section is suspiciously citation-free, so it's fair to take it with a grain of salt.

Is an "average modern high-end car" just a bunch of computers connected together? Each of them is running its own software. Then is the total number LOC in a car actually the total number LOC in each of these computer added up?

Except there may not be any Lines Of Code in any of those computers. The code is the blueprint to make the machine not the machine itself. The program, or binary as some like to call it, does not really come in lines.

How about if we just acknowledge this is debatable and completely beside the point of any of this and save ourselves the time?

Well, interestingly Microsoft claims that Windows is the largest git repo on the planet (2017).

And it looks bigger than Linux by its repo size:

> the Windows code base is approximately 3.5M files and, when checked in to a Git repo, results in a repo of about 300GB. Further, the Windows team is about 4,000 engineers and the engineering system produces 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds.

https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

> by any measure

It should be the world's largest collaboration project on Earth, by the number of contributing companies.

One critical example of such infrastructure is the Linux kernel, used in most servers in the world as well as in billions of devices.

...billions of devices which the manufacturer does not want you to own, to be fair, and for which full ownership requires breaking through the security features that initiatives like this are trying to strengthen. You might think that's a political/social issue and this is merely a technical one, but if the tech advances ahead without such consideration, eventually there might be no way to oppose. That's why things like this always make me feel considerable unease...

"The road to hell is paved with good intentions."

> breaking through the security features that initiatives like this are trying to strengthen

Could you elaborate why Kernel memory safety via Rust impedes “full ownership”?

Memory safety means fewer bugs means harder to root your Android device and use the hardware you paid for in ways you want?

Just guessing. It’s high time we had competitive open-source options in the smartphone space.

Devices like Google Pixel support installing your own rooted Android together with actually adding a new signature to boot loader so you get a fully secure device - it's how projects like CalyxOS can guarantee privacy.

There's absolutely no need to defend security holes in an OS when you have options for proper secure installation of rooted OS available.

You just need to put money where your wishes are and not buy locked down OEM devices.

That is good to know, thank you!

This kind of thing makes it dead simple, too!

https://grapheneos.org/install/web

> it's how projects like CalyxOS can guarantee privacy.

Privacy ≠ security

Secure Boot = security

Sorry, Verified Boot, not Secure Boot, that's MS crap.

It's worth thinking about the consequences, but I don't think a realistic solution is "just don't try to improve software security"

Memory safety issues don't just mean people can root their own devices, they can often mean that outside attackers can root your devices too.

This isn't a theoretical concern, there are known-in-the-wild cases of private and state actors using these device exploits to compromise their users on a mass scale. There are many ways to weigh this tradeoff, but just in pure numbers there may be more people with devices that have been compromised without their unforced consent than people who intentionally root them.

IMO better to trust in legal processes like Software Freedom Conservancy's lawsuit mentioned above to legally enforce the ability for users to root them than to intentionally leave users vulnerable to exploitation through their devices.

GPLv3 tried to prevent this. But as far as I can tell, it has failed miserably with nearly ZERO adoption.

It seems that TiVo-ization is a feature, not a bug.

Zero corporate adoption, for sure. Many projects switched to use GPLv3 and friends, but most corporations will not put one red cent into them. Thus, products are being shipped with the last version that used GPLv2, including packages ranging from bash 4 to Qt 5.6. Having worked on such projects, I can attest that the new status quo is absolutely horrible.

What TiVo actually did (breaking proprietary code when you run modified GPL code) is still allowed by GPLv3. What people are afraid of (disallowing modifications to GPL code) is actually banned by even GPLv2.

https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://events19.linuxfoundation.org/wp-content/uploads/2017...

This is quite an unusual argument against memory safety. Wouldn't it be better to just not buy devices that don't allow root access?

Ultimately this has to be addressed politically. Technical contortions cannot forever make up for what are essentially broken societies and malfunctioning political systems.

I agree; I'm just saying that if we don't let the political side catch up first, we may have our rights taken away with no means to fight back.

The solution to that problem is through law, not inferior technical solutions.

If Software Freedom Conservancy win their lawsuit against Vizio, then anyone who has received a device containing the Linux kernel (or other copylefted code) will be able to sue for compliance, including source code and installation instructions.

https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://sfconservancy.org/blog/2021/mar/25/install-gplv2/

But how long before the kernel itself is replaced and only the modules (under "permissive" licenses) are used? GPL brought us tons of good.

Google already replaced Linux and Android with the Zircon microkernel and the Fuschia OS on some devices. One company (even Google) doesn't scale like an entire community across many companies does though.

https://en.wikipedia.org/wiki/Zircon_(microkernel) https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

Bringing a language whose community growth mindshare teeters on a university license into the kernel would be more destructive than bringing back BitKeeper, but more slow, subtle, and thorough.

Reply on news.ycombinator.com