Conversation

Notices

1. Embed this notice
   Greg K-H (gregkh@social.kernel.org)'s status on Wednesday, 30-Aug-2023 00:55:42 JST Greg K-H
   Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:
   
   - The kernel security team does not have any "early notice"
   announcement list for security fixes for anyone, as that would only
   make things more insecure for everyone.
   
   - The kernel community does not assign CVEs, nor do we deal with them
   at all. This is documented in the kernel's security policy, yet we
   still have a number of people asking for CVE numbers even after
   reading that policy. See my longer "CVEs are dead..." talk for full
   details about how the CVE process is broken for projects like Linux:
   https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/
   
   - You HAVE to take all of the stable/LTS releases in order to have a
   secure and stable system. If you attempt to cherry-pick random
   patches you will NOT fix all of the known, and unknown, problems,
   but rather you will end up with a potentially more insecure system,
   and one that contains known bugs. Reliance on an "enterprise"
   distribution to provide this for your systems is up to you, discuss
   it with them as to how they achieve this result as this is what you
   are paying for. If you aren't paying for it, just use Debian, they
   know what they are doing and track the stable kernels and have a
   larger installed base than any other Linux distro. For embedded,
   use Yocto, they track the stable releases, or keep your own
   buildroot-based system up to date with the new releases.
   
   - Test all stable/LTS releases on your workload and hardware before
   putting the kernel into "production" as everyone runs a different %
   of the kernel source code from everyone else (servers run about
   1.5mil lines of code, embedded runs about 3.5mil lines of code, your
   mileage will vary). If you can't test releases before moving them
   into production, you might want to solve that problem first.
   
   - A fix for a known bug is better than the potential of a fix causing a
   future problem as future problems, when found, will be fixed then.
   
   I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...
   • Haelwenn /элвэн/ :triskell: and clacke like this.
   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 05-Sep-2023 19:38:27 JST Greg K-H

     in reply to

     • Demi Marie Obenour
     @alwayscurious That is not what I am saying at all. You need to understand your usage model and know just exactly what portions of the kernel you are using and design your update schedule around that.
     
     And be prepared to update/reboot at any point in time, after properly testing updates.
     
     Companies using Linux in their "uptime-critical" products usually already know all of this and can handle it just fine. If not, then they are designed and supported wrong and that's a company problem, not a Linux problem.
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Demi Marie Obenour (alwayscurious@infosec.exchange)'s status on Tuesday, 05-Sep-2023 19:38:33 JST Demi Marie Obenour

     in reply to

     @gregkh Are you saying that people who cannot reboot every week should not use Linux?

     That’s a valid position to have, but if it is accurate, it needs to be much more widely known so that embedded systems vendors know not to use Linux for their uptime-critical products.