Google Backs Linux Project To Make Android, Chrome OS Harder To Hack

Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones. From a report: If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet.

Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort. Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages.

The language is not the problem

[denisbergeron]

The algo, the compilator, and the dev are the problem.

Re:

[fustakrakich]

Everybody must report to Google.. Problem solved

Re: The language is not the problem

[ArmoredDragon]

The algo, the compilator, and the dev are the problem.

I've watched C programmers claim that it's easy to avoid security vulnerabilities by just planning your code better. I've also watched C programmers complain about Rust because it forces you to plan your code better.

The first group of them is especially problematic, because the only way you can claim that your code doesn't have any security vulnerabilities is if you're some kind of super programmer that is incapable of producing bugs in their code. That kind of programmer just doesn't exist, and anybody who claims to be that kind of programmer should be trusted the least to write secure code.

The thing with Rust is it guarantees that you can't make certain kinds of mistakes that C offers zero guarantees against. At best you can have a compiler that performs code analysis to look for bugs, but there are never any guarantees.

Re: The language is not the problem

[loufoque]

The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices.

All Rust does is make things slightly more idiot-proof.

If your language mostly relies on marketing about letting bad developers write slightly less shitty code, then most likely it doesn't really add any value.

Re: The language is not the problem

[TuballoyThunder]

Google seems to think people on the internet are a resource to exploit to generate revenue regardless of the individual's preferences. I personally don't think Google is always right and, given their track record of cancelled products, my position is not far fetched

Re: The language is not the problem

[elohssa]

As a bad developer, the idea of less shitty code appeals to me!

Re: The language is not the problem

[MachineShedFred]

As a user who doesn't feel like auditing the entire Linux kernel for shitty code, the idea of automatic guard rails that keep people from writing shitty code appeals to me too.

Re: The language is not the problem

[Pinky's Brain]

The amount of exploits still caused by buffer overflows and use after free's despite tons of tools and auditing to try to catch them is what it is.

Whether they are caused because they are hard to avoid or because programmers on average are just that bad is kinda besides the point to me as a user. From your perspective a slightly more idiot proof language must be an improvement, because most programmers for the software you rely upon to provide you with both direct function and indirect function within the society you live in are idiots.

I personally don't think most programmers are idiots and those flaws are as hard to avoid as to detect within C(++) code, but that's just me. It doesn't change the necessity for Rust.

Re:

[Ostracus]

The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices.

In other words C/C++ programmers get thrown under the bus because all these problems are poor programmers. Almost makes one want to pick up a language that follows good programming practices so the next time the blame train comes around it will not run over the wrong thing.

Re: The language is not the problem

[MrBoring]

The computer does what it is told. The problem is not the soldier, the problem is the general. But let's be honest. How common is a memory error in the kernel? I thought Linus inspects and approve everything and he never makes a mistake.

Re: The language is not the problem

[DrXym]

And yet this "very limited" protection represents perhaps 50% of CVEs that the kernel suffers from. You tell me - if you could eliminate 50% of the bugs from your software making it more secure and reliable, and making your customers happier, would that be a good thing or not?

Re:

[Luthair]

The problem is that in order to write a secure system the programmer must have both perfect knowledge of how the system operates in its entirety, and when they write code they must make zero mistakes. Neither are realistic expectations for complex systems like Linux, so anything that reduces the potential for classes of problems is a step in the right direction.

Re:

[Luthair]

Its not an opinion, in the past I had to look at the precise fixes of hundreds of vulnerabilities and the summary for every CVE for years. If writing perfect code was easy there would be no bugs.

Re: The language is not the problem

[Aristos Mazer]

> The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices.

The major good coding practice that Rust protects you against is using C. :-)
More seriously: I've worked in C code for the majority of my career, and I would NOT consider the protections Rust provides to be easily achieved by good coding practices. Rust gives provable protection against memory sharing, bound overwrites, and thread interaction. Those aren't trivial! Even if you "upgrade" to C++ to have all the OO power for construction-is-allocation, exception propagation, etc, you still fundamentally have a language that allows bad practices and even encourages them in its simplest syntaxes. Rust provides the same low-level memory manipulation and speed of C without the risk.

C++ with warnings

[aberglas]

C++ written with RAII can be made pretty safe. And I would like to see some compiler warnings about pointer arithmetic etc. which would help a lot.

But C++ is a dog.

The biggest problem with Rust is the documentation, which boasts about solving problems that no competent RAII C++ programmer would have. I think there are a few good bits, but they are not made obvious.

You also need to use a different coding style, more like traditional Visual Basic than C. Using Array Vectors instead of linked pointer struct

Re:

[ChunderDownunder]

You also need to use a different coding style, more like traditional Visual Basic than C

I believe rust grew out of the founder's experience with OCAML.

C won't be bulk rewritten in Rust because of the syntax but I wonder if we're discussing robustness through a stricter compiler why safe-C dialects such as Cyclone never took off.

http://cyclone.thelanguage.org/

Re: C++ with warnings

[ArmoredDragon]

While there may be a niche for Rust, most of the kernel could be written in a modern garbage collected language like Java or .Net. They are much more powerful and very efficient if you can resist the temptation to create too much garbage.

Why on earth would you put a garbage collection runtime in a kernel? Especially when you have a language like rust that literally gives you the best of both systems languages and garbage collected languages, with none of their drawbacks?

Re:

[DrXym]

The sticking point is that "no competent RAII C++ programmer". Since that implies there are those who aren't and whose errors end up in the code. And the competence comes from making sure the class instance is non-copyable, or diligently following the rule of 3 / rule of 5 so that when you move or copy the thing around you don't have double frees or other madness. And the rule of 3 or 5 is a pain in the ass and causes its own bugs.

Rust has none of that bullshit. Instances are NOT copyable by default but t

Re:

[DrXym]

Exactly. C requires good programming discipline and while some people might have it, most don't. But even those that do still write bugs that Rust would stop at compile time. This is evident from the number of CVEs that have afflicted the kernel.

C++ does fix some of the issues in C e.g. you can manage resources and memory a little easier, but it's a monster in its own right. It doesn't track object lifetimes and rules governing copy (and now move) are horrific and complex. It also introduces its own subtl

Re: The language is not the problem

[ArmoredDragon]

The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices.

That's like saying that all bugs are easily avoidable by following good coding practices. And it's totally wrong, even when you follow good practices you're bound to make mistakes. You might make fewer mistakes, but the larger your project gets, the more mistakes you'll make anyways.

And saying the types of mistakes rust helps against is "very limited" is disingenuous; it eliminates the possibility of entire classes of bugs, including non-memory bugs like concurrency.

Re:

[WaffleMonster]

That's like saying that all bugs are easily avoidable by following good coding practices.

This makes no sense. How does "The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices." turn into an assertion of "all bugs are easily avoidable"?

And saying the types of mistakes rust helps against is "very limited" is disingenuous; it eliminates the possibility of entire classes of bugs, including non-memory bugs like concurrency.

Rust does not eliminate concurrency bugs.

Re: The language is not the problem

[ArmoredDragon]

This makes no sense. How does "The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices." turn into an assertion of "all bugs are easily avoidable"?

Because there is no single bug or category of bugs that good coding practices will eliminate. It will surely reduce the chance of them ending up in your code, but that is never a guarantee.

Meanwhile, Rust offers that guarantee.

Rust does not eliminate concurrency bugs.

To be specific, it eliminates the possibility of data races:

https://blog.rust-lang.org/201... [rust-lang.org]

Re:

[WaffleMonster]

Because there is no single bug or category of bugs that good coding practices will eliminate. It will surely reduce the chance of them ending up in your code, but that is never a guarantee.

Even if for the sake of argument it is stipulated the statement above is true how does falsely asserting a subset of bugs is easily avoidable morph into an assertion that "all bugs are easily avoidable"?

Lets say I came up with a scheme of putting Krusteaz out of business and it proves to be ineffective and misguided or say it works perfectly and everyone is forced to use Bisquick or make their own pancake mix... The notion wanting to put Krusteaz out of business is the same as wanting to put all companies

Re:

[ArmoredDragon]

Even if for the sake of argument it is stipulated the statement above is true how does falsely asserting a subset of bugs is easily avoidable morph into an assertion that "all bugs are easily avoidable"?

Because it equally applies to any kind of bug, not just the ones that Rust offers guarantees against. There is no rhyme or reason why his statement would be limited in scope to just the kind of bugs Rust offers guarantees against.

Lets say I came up with a scheme of putting Krusteaz out of business and it proves to be ineffective and misguided or say it works perfectly and everyone is forced to use Bisquick or make their own pancake mix... The notion wanting to put Krusteaz out of business is the same as wanting to put all companies out of business is not something that I understand.

Probably because that is a terrible analogy.

In big bold faced text Rusts very own official documentation stipulates "However Rust does not prevent general race conditions."

Hence I specified that it applies to data races.

Re:

[WaffleMonster]

Because it equally applies to any kind of bug, not just the ones that Rust offers guarantees against.

What loufoque said was "The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices."

What loufoque did not say was "All mistakes are easily avoidable by following good coding practices"

You are asserting both statements are effectively the same without offering a compelling reason why that would be the case. All you have done thus far is assert an equivalence exists between statements without explaining WHY you believe that to be the case.

There is no rhyme or reason why his statement would be limited in scope to just the kind of bugs Rust offers guarantees against.

I sus

Re:

[ArmoredDragon]

You are asserting both statements are effectively the same without offering a compelling reason why that would be the case. All you have done thus far is assert an equivalence exists between statements without explaining WHY you believe that to be the case.

I did. Many times.

I suspect the reason loufoque decided to explicitly limit scope is these things are relatively easy to systematically address generally while other types of problems have no reasonable general solution.

This is where you're confused: he said mistakes can be avoided, he didn't say anything about solutions to problems. Those are very different things. But assuming that's what you meant (even though your words say otherwise,) be specific here: Name the types of programming mistakes that can't be avoided (or otherwise mitigated, as I'm asserting) with better coding practices.

What you said was "it eliminates the possibility of entire classes of bugs, including non-memory bugs like concurrency." which is of course incorrect.

Which is why I qualified it.

Re:

[WaffleMonster]

I did. Many times.

You have failed to do so on even a single occasion.

This is where you're confused: he said mistakes can be avoided, he didn't say anything about solutions to problems.

The phrase "I suspect" means what to you?

Which is why I qualified it.

Separately AFTER you were called out on it. More importantly the "data race" language is effectively meaningless as a "class of bugs". People care about race conditions. Saying there are no data races means squat in the real world. Well yea this answer is wrong but hey at least the data was not clobbered is not a thing. It's like doing uncommitted reads in a database and thinking you've accomplished something u

Re:

[ArmoredDragon]

You have failed to do so on even a single occasion.

I even did so in that very post you replied to. That you are unable to comprehend it doesn't matter to me.

The phrase "I suspect" means what to you?

It means that you've either got some very bad reading comprehension or your sleuthing skills are terrible. Either way, you're nowhere close, and it says a lot about your understanding, or lack thereof, of the subject at hand. Disagree? Then either answer the question or quietly acknowledge that you're arguing about nothing.

Separately AFTER you were called out on it.

"called out"? You mad bro?

My statement wasn't incorrect, it just wasn't specific

Re:

[angel'o'sphere]

The kind of mistakes that Rust protects you against is very limited and easily avoidable by following good coding practices.
There is no good coding practice that prevents you from free-ing a pointer twice or forgetting to free it.
And the first one is a real problem if the malloc/free library is not robust. And it is a performance problem, if the library is robust.

Actually, I consider people who make arguments like yours: idiots. And your final sentence nails it: If your language mostly relies on marketing a

Re:

[drsquare]

The kind of mistakes that airbags and seatbelts protect you against are very limited and easily avoidable by following good driving practices.

Re:

[DrXym]

The easiest way to see what impact Rust could have on code quality is to look at the CVE database [mitre.org]. A substantial % of CVEs are for for things like invalid pointers, double frees, data races, buffer overflows etc. Rust either doesn't allow those things by design or fails at compile time.

And I think we can all agree that the kernel probably has a higher threshold for coding quality and inspection than most source code. So even having super programmers will not save a project written in C. And most software

Re:

[Anonymous Coward]

The easiest way to see what impact Rust could have on code quality is to look at the CVE database. A substantial % of CVEs are for for things like invalid pointers, double frees, data races, buffer overflows etc. Rust either doesn't allow those things by design or fails at compile time.

I'm waiting patiently for someone to write better software in their favorite better language. We've been hearing for literally decades how x language is better yet nothing of consequence ever seems to get written in it and the excuses are always predictably the same.

When can we expect good web browsers, operating system, codecs, AAA games, network stacks, databases or really anything to get written in (insert language here) with better results? Will we have real hoverboards and working fusion reactors by

Re:

[dowhileor]

My opinion is; C was written to create memory abstraction and to access that memory as was the concept we call a kernel. So C was a language created to make workable kernels. What C does not do well is define an undefined environment of scaling to users, basing calls to the system on an undefined scale, scope. and it does not provide a easy to use policy for writing user application on an undefined scope, scale as it is assumed memory, hardware are finite resources. So what C does is, given a definition of

Re:

[lsatenstein]

The algo, the compilator, and the dev are the problem.

I've watched C programmers claim that it's easy to avoid security vulnerabilities by just planning your code better. I've also watched C programmers complain about Rust because it forces you to plan your code better.

The first group of them is especially problematic, because the only way you can claim that your code doesn't have any security vulnerabilities is if you're some kind of super programmer that is incapable of producing bugs in their code. That kind of programmer just doesn't exist, and anybody who claims to be that kind of programmer should be trusted the least to write secure code.

The thing with Rust is it guarantees that you can't make certain kinds of mistakes that C offers zero guarantees against. At best you can have a compiler that performs code analysis to look for bugs, but there are never any guarantees.

Biggest problem in code from lazy or inexperienced programmers is the failure to check return codes. Return codes that report buffer overruns, or other.

Re: The language is not the problem

[ArmoredDragon]

Name even one active programmer who hasn't had any bugs in their code in the last year. At the end of the day, security vulnerabilities are just bugs.

Re:

[Ostracus]

Isn't that victim blaming at it's finest?

OpenBSD

[JBMcB]

OpenBSD is written almost entirely in C, and is extremely secure. That's because the developers put an emphasis on security, and the man pages for functions in OpenBSD reflect that.

Re:

[Gavagai80]

And because OpenBSD supports so little hardware that it's a small fraction of the size of the Linux kernel. A smaller, slower-evolving code base is always easier to secure.

Re:OpenBSD

[metrix007]

OpenBSD also has an inflated reputation because people like to accept random things they hear as true.

OpenBSD gained reputation for being secure 20 years ago simply by having everything disabled by default, which is common now but wasn't then. And yes, they maintain OpenSSH and audited some packages, but that's it.

They have always strongly resisted introducing anything like MAC (SELinux, AppArmor) which would really make the system secure. At this point I'd rather run NetBSD which has some nice features like VeriExec. OpenBSD security is a myth, and it's no more secure running it on a gateway than any other stripped down hardened *nix system.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[whitroth]

Got it in one.

Oh, and management has to alot time to *do* security; "get it working, and we'll bolt on security later" means "it'll never happen".

If they really wanted a secure system

[al0ha]

The problem is already solved by a Caltech alumnus - of course not for FREE... But then you get what you pay for with FREE.

The title of the presentation is, "Software That Never Fails and Can’t Be Hacked"

https://www.youtube.com/watch?... [youtube.com]

Re:

[Ostracus]

I think the compromise is "never fails and can't be hacked" be at the bottom-most layers.

Re:

[znrt]

i decided to check that link just because of your fz quote.

i hurried past the pompous introduction and self-gloating, past the embarrassing caltech ceo nonsense ... and really had enough halfway through the "alumnus"'s doom calling.

if he actually does emit some interesting idea or concept please provide an one-liner abstract and/or a timestamp and i will be delighted to retry.

Re:

[Ostracus]

Maybe something about treating code like one treats mathematics with lots of proofs. The whole thing is rather information poor and long on, ah somethings wrong with the world.

Re:If they really wanted a secure system

[Aristos Mazer]

If you want to treat code more like math, you should try programming in ACL2. You write pre and post conditions for parameters as part of every function and the compiler emits a human-readable mathematical proof of correctness as part of compilation. AMD uses ACL2 as their language for the details of their chips. I've seen rendering engines written with ACL2 that can prove the graphics correctness for all edge and corner cases. It's quite a potent language -- LISP variation -- with good performance characteristics.

Actually ...

[fahrbot-bot]

Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages.

Noting that "old" doesn't mean obsolete and it's not necessarily more vulnerable to hacks but rather more vulnerable to poor/unsafe programming techniques -- that make the results more vulnerable to hacks. The kernel could be re-written/updated in C using better practices, but using a "safer" language makes it easier to not have to think/worry about those things. On the other hand, re-writing it in Rust means re-proving the new code is correct. I expect problems either way... Generally, I'd rather update working code than port it and/or generate new code from scratch.

Re:Actually ...

[Waffle Iron]

The kernel could be re-written/updated in C using better practices, but using a "safer" language makes it easier to not have to think/worry about those things.

Not really. If you've ever tried writing a program in Rust, you'll find that the compiler pounds you over the head with those things and refuses to generate a binary until you use better practices.

Re:

[fahrbot-bot]

The kernel could be re-written/updated in C using better practices, but using a "safer" language makes it easier to not have to think/worry about those things.

Not really. If you've ever tried writing a program in Rust, you'll find that the compiler pounds you over the head with those things and refuses to generate a binary until you use better practices.

Thanks for info, though I meant some languages won't allow dangerous things or the resulting program will complain/die at runtime when they occur whereas C will allow them and/or the program will keep right on running.

Re:

[angel'o'sphere]

or the resulting program will complain/die at runtime when they occur whereas C will allow them and/or the program will keep right on running.
A program dyeing at runtime will do so before it has performed an erroneous action and will produce an error and a stack trace showing what happened. A C program in a similar situation will execute the erroneous code and sooner or later crash. There is no safe "the program will keep right on running".

Re:

[fahrbot-bot]

There is no safe "the program will keep right on running".

I didn't mean to imply there was and/or that doing so would be a good thing, just that it's an artifact of the language's lack of safeguards. (Said as a long-time C programmer)

Re:

[angel'o'sphere]

It is basically random if the C program keeps running or crashs.
Depend on the problem. Buffer overflow, most likely a crash sooner or later.
Forgot to free some memory - either the program gets "out of memory" eventually - or it is no problem as the program, e.g. a C compiler terminates before that.
Double free some memory: most likely a crash.

Re:

[NoSpamPlease]

... which you can do with C, just turn on the --pedantic flag and then don't stop changing your code until it compiles clean. I'm not saying they should not try using Rust, just that a large part of the problem is the mindset of the developers who ignore all the warnings the compiler is already generating. I guess Rust solves this by not having a non-pedantic mode, partly.

Re:

[Waffle Iron]

I always use the pedantic flag if I'm writing C code, but sorry, it's not even in the same league as Rust when it comes to strictness. My estimate is that -pedantic might catch 25% of the things that Rust enforces.

Re:

[Aristos Mazer]

I would agree with that estimate, especially in any multithread application.

Re:

[Anonymous Coward]

I keep seeing comments like this and what you need to do is stop and consider why there's still drive to replace chunks of the Linux kernel with Rust if it's as easy as this. A whole bunch of people have looked at it and decided that it's at least worth a try to code up some chunks of the kernel in Rust because despite everyone on slashdot apparently being an expert, a whole bunch of people that have a stake in Linux being secure have come to the conclusion that it's not enough to turn on the --pedantic fla

Re:

[packrat0x]

I predict, with Rust, the kernel will be approximately 4x bigger and waste cache. Cache which would be better used for applications. The kernel does not produce useful results, it is overhead. It needs to be small as possible so it can stay out of the way. Memory is cheap, but cache and registers are the bottleneck to performance.

Re:

[jerryjnormandin]

You are correct! Also it won't be as easy as it is to support all the architectures that Linux supports. Google is evil. They should bug out. C is more efficient and leaner than Rust. I am willing to bet they will end up with a huge kernel that is slow at accessing registers and cache. I like to use the best Language for the operation. Kernel and low level stuff is C and Assembly !

Re:

[SirSlud]

Wow, imagine if the Linux kernel contributors knew that!

Re:

[UnknowingFool]

The issue with C is not that it is old; it simply was not designed with some of these security considerations in mind. The problem with rewriting C to be have these security features is exactly why Rust exists. You are basically asking people to do what they have already done.

Re: Actually ...

[loufoque]

Rust is not just safe C.
It's a strongly opiniated language made by people who misunderstood how to use C++.

C, on the other hand, is a pragmatic no bullshit language, that among others doesn't require adhesion to a cult to use.

Re:

[fahrbot-bot]

C, on the other hand, is a pragmatic no bullshit language, that among others doesn't require adhesion to a cult to use.

No argument here ... been using it since the 80's.

Re:

[DrXym]

"C doesn't require adhesion to a cult to use", says someone acting defensively when confronted with a language which is demonstrably safer. Tell me again who has the cult like mentality?

Re:

[UnknowingFool]

Rust was designed to handle the exact issues the OP is proposing to modify C. That is like saying I should not use a pickup truck to haul a large bale of hay; I should modify my sedan and replace the frame, drive train, and engine to haul that bale.

Re:

[mlw4428]

Ugh. C is assembler for people who didn't enjoy assembly. Its use cases are limited these days and for the vast majority of developers and scenarios and considering modern hardware - it's time to accept that modern languages that incorporate features (like .NET's managed code) is THE way to go for the vast majority of development.

Re:

[SirSlud]

Ironically you couldn't manage to write this without sounding pretty darn tribal yourself.

Re:

[jerryjnormandin]

All you need to do is write your own security features in C. It's not hard. Too many coders now are dependent on APIs. When I started out in my career one of my first projects was writing firmware for a networkable door access control system. ALL in assembly. With the labels I used my assembly look like a unique language. I even wrote a process scheduler that used timers and semaphores. All on a 8051 embedded controller. And it was never hacked. I did hack a fellow employees design by generating lots

Re:

[jerryjnormandin]

I forgot to add by networkable I mean old school RS485 X.25 protocol

Re:

[DrXym]

Rewriting for the sake of rewriting is a terrible idea and I doubt anybody was seriously contemplating that.

Re: Actually ...

[Pimpy]

Itâ(TM)s also a stupid comment made by someone thatâ(TM)s clearly never done kernel development for any significant amount of time. The kernel makes heavy use of modern C extensions and standards, and often drives changes standardization (often done jointly with the glibc folks). The kernel also makes rather heavy use of preprocessor macros and inline assembly that makes it a challenge even for non-gcc C compilers to build, though the use of gcc-specific extensions has reduced in recent years as o

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[fahrbot-bot]

I hope you were speaking in generalities because that's not what I was saying. But, using Rust won't be a panacea for all the programming woes of the original C code and rewriting things, even in Rust, may bring new bugs and problems. Some things may be better redone in Rust, some may be better left in C and updated.

Also, you sounded a bit jerky and should work on your delivery...

No thanks

[intvector]

Hundreds of megabytes of additional bloat dependencies in kernel? No thanks. Time to make a Rust-less fork of Linux (no pun intended).

Re:

[UnknowingFool]

The Linux kernel is around 110 MB currently. I do not see how the kernel explodes into hundreds of MB by changing the code to use Rust in parts. Remember this entire thread is about changes to the kernel not the entirety of Linux which can be huge depending on what software that is added.

Re:

[Mononymous]

The entirety of Linux is the kernel. If you're marketing something else as "Linux" you're abusing the trademark.

Re:

[UnknowingFool]

No you missed the whole point: the current kerne 5.1.211 is 112MB. Using Rust instead of C in parts does not explode the kernel into hundreds of MBs either in the source code or when compiled.

Re:

[intvector]

Read my post again. I said "dependencies", not source itself. I don't want to install Rust, nor should anyone be required to to compile the kernel. And yes, Linux *is* the kernel, usually used in combination with the GNU OS.

Re:

[DrXym]

Rust compiles onto bare metal devices like arduino boards. Why do you suppose there are any additional runtime dependencies?

Re:

[intvector]

There are compile time dependencies. I don't want to install Rust, nor should it be a requirement to compile the kernel.

Re:

[DrXym]

Yes. And?

Re:

[intvector]

And Gentoo, Kiss Linux, or simply anytime user decides to compile the kernel instead of downloading a binary. "And" we go back to my OP.

Re:

[DrXym]

So Gentoo sticks Rust compiler onto their live environment which is used to bootstrap the rest of the system and that's that. Big deal.

Re:

[intvector]

And now I see you don't know how GNU/Linux even works. You don't need to boot from Live USB every time kernel is updated, you compile and install it from your working system. It is a big deal, because big tech is trying to get a grip on Free software community in every way they can. Linux was one of the few still holding bastions of freedom. Thanks to the GPL (even if it's the weak v2, locked in by Linus on purpose), there is a way out in the form of a fork, just like it was done with systemd.

Re:

[DrXym]

Rust is big tech? Interesting.

Re:

[intvector]

Google and Mozilla are big tech companies which rely on spying their users. Whatever Google, Mozilla, Microsoft, Amazon, Apple, etc promote is likely to be corpo junk and not beneficial for the users.

Re:

[DrXym]

Mozilla don't own Rust. Nor do they spy on their users. Nor are they "big tech". And if you're that paranoid I suggest you review the source code. Or perhaps even review who the major contributors to the Linux kernel are these days.

Re:

[intvector]

Mozilla does spy on its users, just like Google. There are websites covering this topic in detail. That's why forks like ungoogled-chromium and Librewolf exist.

How can they prove NSO

[diffract]

don't have the tech to hack the phone?

Obvious question

[ChunderDownunder]

(and kinda hinted at at the end of the article)

why is Google still basing Chrome OS and Android on Linux?

They have Fuchsia, as recently rolled out in production to Nest.

Chrome OS is a V8 virtual machine. Android is a Java-like virtual machine. Why should either runtime care what the underlying OS is?

Crostini can run as a VM on top of Zircon, surely.

Re:

[angel'o'sphere]

Chrome OS is Linux.
Android is Linux.

The virtual machines are the containers hosting/running the Apps. Has nothing to do with the OS at all.

Re:

[iampiti]

I don't know. The situation has probably changed a lot over the years. But some years ago I worked on a device that used an old version of Android and many low-level userland libraries where the same as those used on common Linux distros so..they probably had some kind of dependency on Linux that maybe Fuchsia still doesn't satisfy.
I don't even know (nor do I care to search) whether Fuchsia is or tries to be POSIX-compatible so much of those glue libraries I was talking about (they were between the kernel

Looking in the wrong place

[Pimpy]

The kernel has a pretty good security track record, if they want to find areas that need to be improved, they might start with that massive Java runtime theyâ(TM)ve layered on it and forced every app to go through.

Every few years a new language replaces C again

[a-zA-Z0-9etc]

If I'd bought all the books about all the new languages which at one time or another were claimed to be about to replace C then I'd have several more bookshelves of books that I never refer to than I actually do. In no particular order, and certainly not a complete list, I can think of Objective C, C++, C#, Rust, D, Swift, Java, Go, Dylan, INTERCAL. Some of these languages are used more than others, some have niches in which they're successful, some are as good as forgotten (I've not opened my Dylan book in

Re:

[iampiti]

Yeah, C is very much entrenched in some niches and has compilers for all kinds of hardware but you can never discount new languages getting themselves into some previously-mostly-C niches. Some of the languages you mention I don't think no one actually believed they could replace (at least completely) C. Both C# and Java are VM, garbage-collected languages with huge runtimes and requiring lots of RAM. I don't think even their creators thought they could replace C.
Rust does seem to be gaining quite a bit o

Is there a reason to lower the bar?

[Goatbot]

Rust has advantages no dispute there. That said should we make it easier to code for the Kernel IDK. Kinda like why fix what is not broken. As it is my developmental boxes are filled with compiler related requirements as I build my systems from source.

C is not more vulnerable.

[jerryjnormandin]

Who writes this crap ? C is not more vulnerable. Any language is vulnerable. You can write insecure code in Rust, Python, Perl, PHP, C, Java, and all high level languages. It depends on the coder. If a C library has a security flaw, you can write your own library. It's no big deal. I bet I can write a Rust exploit. Do you know the IP stack is vulnerable ? Despite all the firewalls and proxies, due to the structure of the IP stack it can still be hacked. IPV4 and IPV6 are vulnerable. If you have

Re:

[ebvwfbw]

Looking at the other comments it looks like we have yet another flame war. Like between SYS V and BSD, Gnone and a professional looking desktop like KDE. RedHat and Debian. Wish debian would just go away.

LOL, Some of the comments remind me of SNL. Dan Aykroyd and Jane Curtain. Jane you ignorant slut. bla bla bla... Jane would respond Dan you pompass asshole bla bla bla... Funny bit.

You C people, you ignorant slut...It's terrible. Being a C guy myself - You pompass assholes... it's secure if you are a real p

Re: Wrong language

[Goatbot]

Umm u serious? I've done some good coding in Pascal but not sure I would want to use it for the Linux Kernel.