Linux Kernel Security Done Right(security.googleblog.com)
security.googleblog.com
Linux Kernel Security Done Right
https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html
5 comments
> This "upstream first" approach to product kernel development and testing is extremely efficient. Google has been successfully doing this with Chrome OS and Android for a while now, and is hardly alone in the industry.
This seems to be conflating testing a product against an upstream kernel and making your stable Linux distribution use an upstream kernel. A huge number of open source projects and vendors already do the first thing without any difficulty. I believe that doing the second thing is much rarer. Do Google do both things?
This seems to be conflating testing a product against an upstream kernel and making your stable Linux distribution use an upstream kernel. A huge number of open source projects and vendors already do the first thing without any difficulty. I believe that doing the second thing is much rarer. Do Google do both things?
I used to put main kernels compiled for a very standard distro, on production, and manually updated twice a month after testing a bit each release.
You're almost never safe. But I agree some testing helps. Anyway not everyone has the infra and/or resources.
* One time I dodged a data corruption bug with a default, common filesystem, that obviously got rapidly patched.
* Last time and very recently, main kernel introduced a bug that made NFS just don't work for clients trying to connect, until a patch was released and applied for those servers.
You're almost never safe. But I agree some testing helps. Anyway not everyone has the infra and/or resources.
Feel free to start with asking engineers more security related questions, cuz you know - poorly performing algo can be rewritten meanwhile leak cannot be reverted
https://www.linuxfoundation.org/press-release/google-funds-l... Maybe Google could offer to fund 20% of a bug fixing dept. If Huawei, Intel, Samsung, AMD, and Google each put up 20 employees, it could get done.
What I'm also hearing here is 'vendors shouldn't work on their branch but contribute to main/stable branches' and I'm here wondering how you can ever ship anything tested (since it's part of the subject) with this lack of control of branch history. Starting from something you know works, and increasingly upgrade/fix is the only manageable way to ship something as complex and untested as upstream Linux.
The solution is 'add 4 guys to your team and fix our coders' bugs before they ship'? So, fun coding and good PR for some, drudge of shitbugs and abuse on lkml for others.