# Google slams Linux kernel



## drhowarddrfine (Aug 7, 2021)

Needs major investment in security



> Kees Cook from Google’s Open Source Security Team compares the Linux kernel to the US automotive industry of the 1960s in order to drive home the point that while the kernel runs flawlessly, when it fails, it falls apart miserably.


----------



## a6h (Aug 7, 2021)

drhowarddrfine said:


> Needs major investment in security


Old gem from the dude-in-chief:


> Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of *masturbating monkeys*, in that they make such a big deal about concentrating on security to the
> point where they pretty much admit that nothing else matters to them.


----------



## bsduck (Aug 7, 2021)

> “Instead of testing kernels after they're released, it's more effective to test during development,” suggests Cook


This sounds like common sense to me. The fact it is a "suggestion" shows the current development model is flawed.


----------



## Tieks (Aug 7, 2021)

Kees Cook doesn't mention Android. Do they test before a new release?


----------



## drhowarddrfine (Aug 7, 2021)

I think Android is pretty heavily modified


----------



## hardworkingnewbie (Aug 7, 2021)

You can consider Android as a heavily modified fork of the Linux kernel. Google put much of their own stuff into it, and put many NetBSD tools into it instead of the usual GNU ones.


----------



## tux2bsd (Aug 7, 2021)

Google want to establish (more?) control aka "invest".  

Google refuse to do security properly as it is.  How many billion Android devices are out of security support?


----------



## mark_j (Aug 8, 2021)

tux2bsd said:


> Google want to establish (more?) control aka "invest".
> 
> Google refuse to do security properly as it is.  How many billion Android devices are out of security support?


Correct.
Google's solution lies here! They could dump that wanna-be O/S called Fuschia and adopt FreeBSD. It works on most ARMs, has a permissive licence so they can do what they please and we might even get a better OS for it. A win-win.

*FreeBSD foundation: Get your arses/asses off to Google post haste!*


----------



## Deleted member 30996 (Aug 8, 2021)

> I think the OpenBSD crowd is a bunch of *masturbating monkeys*, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. - Kees Cook



I think he's a cat caboosing coward.

I'm calling you out again.

Here, kitty kitty kitty...


----------



## sidetone (Aug 8, 2021)

I don't think we should be prodding Google, at least not beckoning them in that way. Criticizing where deserved is another story.

If that were a complaint from a small company, then it would make sense. but from a multi-billion dollar company that can afford to write its own kernels? That's his job to fix. "It's a nightmare for us" to fix it. Well, you can afford to write 50 unique kernels from scratch, if you wanted to. Seriously, he complains about OpenBSD security as being too focused on security, but criticizes Linux security as a task to implement, which he can more than afford to pay workers well to fix it or write a new kernel. Or he expects OpenBSD and Linux to do his job for him.

Aside from that, maybe they want something like a Minix kernel instead of a Linux one. Then again, I'm not interested in that guy's opinion, and I'm not a fan of what goes on around the Linux kernel.


----------



## a6h (Aug 8, 2021)

> monkeys


I found the video. The "Monkey" reference, timestamp 00:03:00 @ _Hackfest 2015: 23.11.2015_


----------



## ralphbsz (Aug 8, 2021)

mark_j said:


> Correct.
> Google's solution lies here! They could dump that wanna-be O/S called Fuschia and adopt FreeBSD. It works on most ARMs, has a permissive licence so they can do what they please and we might even get a better OS for it. A win-win.


I'm not sure whether you mean this, or whether you are intending this as a joke.


----------



## grahamperrin@ (Aug 8, 2021)

LKML: "Theodore Y. Ts'o": Re: 5.13.2-rc and others have many not for stable


----------



## drhowarddrfine (Aug 8, 2021)

ralphbsz said:


> I'm not sure whether you mean this, or whether you are intending this as a joke.


I was going to say that it's too big to change the course of that ship but, then again, they did make Fuschia.


----------



## Deleted member 30996 (Aug 9, 2021)

sidetone said:


> I don't think we should be prodding Google, at least not beckoning them in that way.


"We" didn't do anything. I did.

I was an OpenBSD user in 2015 when he said that. I can attest to the fact that every monkey in that room was typing Shakespeare.

I hit on hottie Google geek girl, Mary Lou Jepsen, too. I bet she's got one of the wallpapers I made for her on her desktop right now.


When I was at GeoCities, promoting my first site on the Boards, I saw a guy picking on Don Garlits. 

Big Daddy Don Garlits who I had admired since a child.

Uh oh...

I showed that guy how it felt to get picked on, administered some bad Karma and saved my childhood Hero.

He had a GeoCities site which reflected his belief in UFO's. I asked him privately if he didn't worry about what people might think.

He said "I'm Big Daddy Don Garlits. I'm famous. I don't give a damn what they think."

That was my first day on the job as an Independent Agent of Chaos of more than 20 years.
Everyone who is famous has Fame, but not everyone who has fame has infamy. 

I do and I don't give a damn what he thinks.


----------



## sidetone (Aug 9, 2021)

Trihexagonal said:


> "We" didn't do anything. I did.


Ok. lol

I was also referring to another response as well. I didn't agree with the FreeBSD Foundation action comment in principle. I don't see that doing any good. If they do come to FreeBSD, screw it, but I don't think it's good influence.


Trihexagonal said:


> was typing Shakespeare.


Which one?

Well, I criticized his comments anyway. That was too much to say coming from someone who can afford to have 50 unique kernels written, then criticizes something he gets for free.


----------



## kpedersen (Aug 9, 2021)

sidetone said:


> That was too much to say coming from someone who can afford to have 50 unique kernels written, then criticizes something he gets for free.


In many ways I think we are in this strange situation where a secure kernel simply cannot be made by paying people. It needs to come from true open-source and it needs to be written via passionate people. It takes time and effort. I don't feel people simply doing a paid job are able to give that. Especially since it will take millions of man hours.

The Linux kernel is a jumble sale of everyone pushing their agendas and doing it quickly to "be the first". That and hardware vendors doing the absolute minimum to get their hardware out there as soon as possible. This cannot produce a secure system.

OpenBSD is unlikely an option due to their tendency to *not* play ball with companies like Google. In the past they have have had issues with DARPA funding because they wanted to do what they wanted and say what they wanted. Ultimately I feel this is the best stance to have for a high quality output though. Just Google can't benefit!

FreeBSD is a little more relaxed with corporate influences, though not quite as much as Linux (whether this is due to opportunity or opinion is another matter). So if Google wants a secure kernel, I feel FreeBSD will be their best choice going forward. Obviously this will royally screw up everything that is good currently. They will suck the project dry.


----------



## sidetone (Aug 9, 2021)

Google should go with Minix's kernel. It's everything he wants anyway.

Google will push too much weight around, maybe away from what FreeBSD has always been.


----------



## astyle (Aug 9, 2021)

> “Instead of testing kernels after they're released, it's more effective to test during development,” suggests Cook





bsduck said:


> This sounds like common sense to me. The fact it is a "suggestion" shows the current development model is flawed.


What evidence do you guys even have that testing is not done "during development"? This thread may be in the off-topic section, but all I see is bandwagoning around some bashing comments from someone in this thread, rather than any kind of informed discussion/debate.


----------



## sidetone (Aug 9, 2021)

That's Cook's quote. It's implied that according to him, it's not enough or it isn't.


----------



## hardworkingnewbie (Aug 9, 2021)

kpedersen said:


> In many ways I think we are in this strange situation where a secure kernel simply cannot be made by paying people. It needs to come from true open-source and it needs to be written via passionate people. It takes time and effort. I don't feel people simply doing a paid job are able to give that. Especially since it will take millions of man hours.
> 
> The Linux kernel is a jumble sale of everyone pushing their agendas and doing it quickly to "be the first". That and hardware vendors doing the absolute minimum to get their hardware out there as soon as possible. This cannot produce a secure system.


I think the major difference between Linux and the FreeBSD kernel is the number of eye balls having a closer look at it. This number is much, much bigger at Linux compared to FreeBSD. Would FreeBSD have the same number of eye balls taking a closer look, oh boy, I am pretty sure the number of found exploits would skyrocket.


----------



## drhowarddrfine (Aug 9, 2021)

hardworkingnewbie said:


> the number of eye balls having a closer look at it.


I've read a few papers, over the years, that debunk that thought. Something along the lines of those eyeballs are mostly people who don't know what they're looking at and only create a lot of distracting noise. Fewer experienced eyeballs means better focus.


----------



## hardworkingnewbie (Aug 9, 2021)

And I think these papers underestimate the principle of the more people are looking, the more comes to light, a lot.


----------



## astyle (Aug 9, 2021)

hardworkingnewbie said:


> And I think these papers underestimate the principle of the more people are looking, the more comes to light, a lot.


If you see a hundred people on the street, what are your chances of seeing a doctor walk by? If you go to a hospital, and see a hundred people walk by, your chances (of seeing a doctor walk by) go up dramatically. And what if you actually need a doctor? Same with looking at kernel source code.


----------



## kpedersen (Aug 9, 2021)

I believe that due to Microsoft's collection of Shared Source / University / Internal business agreements, there are probably more eyeballs looking at the NT kernel code than FreeBSD. Does that make Windows more secure? I am not convinced.

A lot of the Linux kernel source code is very rarely looked at (and very rarely properly audited). It has been dumped in there by some vendor and forgotten about. So again, I don't know if we can classify Linux as more secure. Certainly some code paths *do* have greater coverage in terms of verification.

In many ways I would be really interested in some sort of measurement / experiment here. I think the best we can do is with static analyzers but very few of them can find new issues in any of the projects.


----------



## Beastie7 (Aug 9, 2021)

kpedersen said:


> The Linux kernel is a jumble sale of everyone pushing their agendas and doing it quickly to "be the first". That and hardware vendors doing the absolute minimum to get their hardware out there as soon as possible. This cannot produce a secure system.



Bingo. 

No common engineering principles and/or values amongst a community governing software; you get something like the Linux kernel. The Linux kernel should be called the "Driver Bucket".


----------



## astyle (Aug 9, 2021)

kpedersen said:


> I believe that due to Microsoft's collection of Shared Source / University / Internal business agreements, there are probably more eyeballs looking at the NT kernel code than FreeBSD. Does that make Windows more secure? I am not convinced.
> 
> A lot of the Linux kernel source code is very rarely looked out. It has been dumped in there by some vendor and forgotten about. So again, I don't know if we can classify Linux as more secure. Certainly some code paths *do* have greater coverage in terms of verification.
> 
> In many ways I would be really interested in some sort of measurement / experiment here. I think the best we can do is with static analyzers but very few of them can find new issues in any of the projects.


Well, gotta keep your eyes peeled in that case, to avoid another UM debacle. The more eyeballs you have, the more likely you are to have a repeat from a few bad apples.


----------



## Crivens (Aug 10, 2021)

Don't forget: the number of bugs found doesn't matter. The number of bugs reported does. And the ratio between them even more.


----------



## sidetone (Aug 10, 2021)

hardworkingnewbie said:


> I think the major difference between Linux and the FreeBSD kernel is the number of eye balls having a closer look at it. This number is much, much bigger at Linux compared to FreeBSD. Would FreeBSD have the same number of eye balls taking a closer look, oh boy, I am pretty sure the number of found exploits would skyrocket.


It's not the case at all. Most opensource users are like a school of fish that get a confirmation of numbers which doesn't mean much. Linux/GNU has a lot of problems, and it took putting those programs on FreeBSD to find out problems with it. The way I found this, is because it was either make an improvement, or continue to compile 14 hours of bloat for no reason. For GCC, it took an additional 14 hours, because it pulled in sets of Linux dependencies for 3 Operating Systems worth. I replaced that with Clang, and 14 hours of compile time were dropped off. After pointing that out, they fixed GCC on FreeBSD. That took 1 user to find, after several years of using this OS, when Linux/GNU kept piling on, and we ported that way here. How many security holes are in that, if they didn't even know why they added that many unneccessary dependencies, that took hours to compile?

OpenBSD has less eyes than FreeBSD, and they'll find more vulnerabilities than Linux, and be somewhere in the ballpark to other BSD's.

Saying one OS has more eyes on it, therefore it's automatically better or more secure, is like the saying that 1 person is vocal, while everyone disagrees with that person, but outloud everyone says they agree, because they think everyone else agrees.


----------



## Beastie7 (Aug 10, 2021)

Linux may have more eyes. But c'mon, since when do eyes fix bugs? brains do. 

I'd rather be protected by a thousand kings, than one king and a million peasants. (yes, I went there)


----------



## tux2bsd (Aug 10, 2021)

Google should go double-or-nothing and roll with GNU Hurd.


----------



## astyle (Aug 10, 2021)

Crivens said:


> Don't forget: the number of bugs found doesn't matter. The number of bugs reported does. And the ratio between them even more.


As Beastie7 pointed out, it's brains that fix bugs, not eyeballs. Just because a bug is reported, that means nothing until you can show that yes, this is a problem that demands attention and a fix, otherwise the situation will get in the way of proper functioning. Otherwise, we're gonna have robots fighting it out over `for(....)` vs `do while(...)`, and humans unable to tell the difference.


----------



## drhowarddrfine (Aug 10, 2021)

astyle said:


> it's brains that fix bugs



Cue the music


----------



## mkru (Aug 10, 2021)

Isn't this one of the reasons why Google is pushing on adding Rust as the second language for Linux kernel development?


----------



## astyle (Aug 10, 2021)

Yeah... Google does have the money to hire the brains.... At one point Vint Cerf did work for Google, after all.


----------



## ralphbsz (Aug 10, 2021)

astyle said:


> Yeah... Google does have the money to hire the brains.... At one point Vint Cerf did work for Google, after all.


He still does.


----------



## kpedersen (Aug 10, 2021)

astyle said:


> Yeah... Google does have the money to hire the brains.... At one point Vint Cerf did work for Google, after all.


Not to mention many of the Google Golang guys are from the old AT&T Bell Labs / C group. Also my particular favorite; Renee French (of Plan 9 Glenda Bunny Fame) for the Gopher mascot!

Oddly enough, along with my search just now I came across a certain Dr BSz too @Google. Seems like a smart guy.


----------



## drhowarddrfine (Aug 10, 2021)

kpedersen said:


> Not to mention many of the Google Golang guys are from the old AT&T Bell Labs / C group.



Hmm. Notice a trend there of where all the original guys from the world's greatest OS are.


----------



## astyle (Aug 11, 2021)

drhowarddrfine said:


> Hmm. Notice a trend there of where all the original guys from the world's greatest OS are.


Google apparently vacuums up data and brains. The rest are left to work on Windows' J++.


----------



## sidetone (Aug 11, 2021)

Why doesn't Google take Minix as a starting point, and rewrite it in Go-lang or Rust? Minix is everything he described he wanted, except it's in neither the language of Google or Rust.

He wants Rust which has safety checks, but Google contributes Go-lang. So why doesn't he add Rust safety features to the next version of Go-lang.

I think Linux should stay as C, unless, there's something closer to C than Rust (and not C++). It seems that it needs to stay as 1 language: either staying as C or a language that's very close so it doesn't need much more in toolchains, or being re-implemented completely in Rust. Rewritting the Linux kernel in Rust is like asking Linus to rewrite everything, which is too tall an order. It could be gradually replaced with Rust code, or with a competing kernel sooner or later.

An Android kernel written in Go-lang modeled from Minix makes a whole lot of sense for mobile phones. A future version of Go-lang with Rust safety features also makes sense. It will give the Minix kernel advertisement it needs, while Minix will remain separate to limit all influence to it.


----------



## mkru (Aug 11, 2021)

Go and Rust serves different purposes and have different paradigm. Incorporating Rust features into Go simply does not make sense.
Google indeed contributes Go, but I guess it is not the kernel team. At least this is the impression I get when watching conference talks on Go given by Google employees.

They do not want to rewrite it in Rust, but allow writing new stuff in it. Old stuff stays C, the new one will be written in Rust.


----------

