I think you could make a stronger case for the opposite. How does Redhat know which commits to cherry when upstream explicitly won't tell you which are relevant to security?
Because Red Hat pays the salaries of dozens (hundreds?) of kernel maintainers all over different subsystems. So they’re subject matter experts, and know exactly which ones are relevant to Red Hat.
Paying maintainers doesn't give Red Hat a magic oracle for "which commits matter for security". What you actually end up with is cherry-picking + backporting. Backporting is inherently messy, you can introduce new bugs (including security bugs) while trying to transplant fixes, and omissions are inevitable. And CVEs don't save you here: plenty of security relevant fixes never get a tidy CVE in the first place, and vendors miss fixes because they often pretend the CVE stream is "the security feed".
Greg is pretty blunt about this in the video linked in the article: "If you are not using the latest stable / longterm kernel, your system is insecure" (see 51:40-53:00 in [1]). He also calls out Red Hat explicitly for ending up "off in the weeds" with their fixes.
RHEL as an entire distribution may provide good enough security for most environments. But that is not the same claim as "the RHEL kernel is secure" or "they know exactly which commits are relevant". It is still guesswork plus backports, and you're still running behind upstream fixes (many of which will never get pulled in). It is a comfortable myth.
I think you could make a stronger case for the opposite. How does Redhat know which commits to cherry when upstream explicitly won't tell you which are relevant to security?
Because Red Hat pays the salaries of dozens (hundreds?) of kernel maintainers all over different subsystems. So they’re subject matter experts, and know exactly which ones are relevant to Red Hat.
Paying maintainers doesn't give Red Hat a magic oracle for "which commits matter for security". What you actually end up with is cherry-picking + backporting. Backporting is inherently messy, you can introduce new bugs (including security bugs) while trying to transplant fixes, and omissions are inevitable. And CVEs don't save you here: plenty of security relevant fixes never get a tidy CVE in the first place, and vendors miss fixes because they often pretend the CVE stream is "the security feed".
Greg is pretty blunt about this in the video linked in the article: "If you are not using the latest stable / longterm kernel, your system is insecure" (see 51:40-53:00 in [1]). He also calls out Red Hat explicitly for ending up "off in the weeds" with their fixes.
RHEL as an entire distribution may provide good enough security for most environments. But that is not the same claim as "the RHEL kernel is secure" or "they know exactly which commits are relevant". It is still guesswork plus backports, and you're still running behind upstream fixes (many of which will never get pulled in). It is a comfortable myth.
[1] https://www.youtube.com/watch?v=sLX1ehWjIcw&t=3099s
This is the right answer.
Source: 10+y long (past) tenure at RH in a team adjacent to the kernel team.
EDIT: also because companies like RH tend to know, and are happy to know, the details of their customers' deployments. Compare the article:
> Always remember, kernel developers:
> - do not know your use case.
> - do not know what code you use.
> - do not want to know any of this.
1 reply →