Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

openwall.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#51

Post by [deleted] »

gbrown wrote: post #45
awill wrote: post #33

Earlier quoted context omitted.

It can be frustrating, but it's almost always worth it in a serious production environment. I have my own anecdote: I have serveral home servers running CentOS 7 (set up nearly 6 years ago). I update all the time and I've had zero issues. Literally nothing has ever broken. My previous servers ran CentOS 6, and were equally reliable. My desktop runs Arch Linux, and gets ever kernel dot release. I've had an unbootable…

Fedora seems like a sensible middle ground.

[deleted]

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#52

Post by bonzini »

brozaman wrote: post #44
mikevm wrote: post #9

I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.

If it's any consolation, I'm a software engineer working for Red Hat on the userspace part of one of our most bleeding edge products, and it's a pain for us too :). And it's a much bigger pain for our kernel guys It would be way cheaper and easier for us to ship a newer kernel, we do it because it allows RHEL to have significantly less regressions than upstream kernels (and I'm talking about what the kernel engineers…

Yes (kernel engineer here), we can mix and match what we pick and when. Almost every major subsystem is updated only a few months after the corresponding patches hit Linus's tree.

I would guess that most of RHEL 7 is on par with 4.14 or 4.19 (which is newer than the RHEL 8 kernel!) and RHEL8.3 will have subsystems updated up to 5.7-5.8.

Of course it's not much fun backporting 50 patches for Intel vulnerability mitigations to RHEL7.2 that some mission critical apps still use. But I guess it pays my bills so who am I to complain, I love everything else about my job. ;)

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#53

Post by baggy_trough »

stonogo wrote: post #20
gregkh wrote: post #7

Earlier quoted context omitted.

They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy. Note, I'm the person who does the LTS kernel releases, maybe they just don't like me :)

It could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.

Why doesn't that argument apply to the mainline kernel?

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#54

Post by drewg123 »

baggy_trough wrote: post #3

Why don't Red Hat et al use the LTS kernels?

RHEL maintains a KABI to support binary device drivers. Given how frequently the linux kernel changes internal APIs, this would be much harder or even impossible if they changed kernel versions regularly.

Instead, they take features and bugfixes from upstream and merge them back into their kernel version, auditing them for changes that would not be binary compatible.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#55

Post by despera »

gregkh wrote: post #46
despera wrote: post #39

While RedHat's backporting might not be great, i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system. It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not. Still there must be a middle ground arou…

And what would that "middle ground" look like? With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?" Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just ta…

I understand that completely and i already know your thoughts on that and in some extend i do agree.

Still, i think we do have in hand a very characteristic issue that even without knowing the details, simply by searching commit messages for "crypto" "key" "buffer" etc it should alert somebody to give it a second and third look.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#56

Post by School-Cotton »

bluedays wrote: post #21
pnutjam wrote: post #15

Earlier quoted context omitted.

No, you can't do that in RHEL. It would invalidate support.

Seems sad that the modularity of Linux is not allowed due to issues with support. That, in my opinion, is the best part of Linux - which is finding solutions to problems that exists outside of the scope of what is designed by the vendors.

Nothing stops people from using whatever distro they like, instead of RHEL. If they are using RHEL, presuming they’re rational actors, it’s because the RHEL model works for their use case.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#57

Post by heavyset_go »

baggy_trough wrote: post #3

Why don't Red Hat et al use the LTS kernels?

Ubuntu does the same thing. I'm only pointing it out because if you can't find a reason RH does it, you might be able to find the reason Canonical does it, though.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#58

Post by bonzini »

gregkh wrote: post #23
stonogo wrote: post #20

Earlier quoted context omitted.

It could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.

Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...) As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)

Android and RHEL are completely different scenarios.

The target of Android, which is who Google has to deal with, is multiple manufacturers creating kernels for custom hardware (often without upstream drivers), with very short product life, relatively little experience with upstream contribution and few needs for new features for a given major release of Android.

RHEL is developed by a single company with a 10 years life cycle, only 3-4 kernel versions to juggle but almost non-overlapping lifecycle (as far as the initial development-heavy phase is concerned). Development occurs upstream first and quite a few engineers are upstream developers or maintainers, so that the number of non-upstream features is very small and almost going down over time, see for example stuff like the secure boot lockdown patches that Matthew Garrett started when he was at Red Hat. And even though the product is not the kernel, we need to backport more features than what goes into LTS, because userspace needs them (user namespaces, driver updates, networking or virtualization optimizations, enablement for new processors, etc.)

So it's only natural that there are completely trade-offs to make.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#59

Post by eqvinox »

despera wrote: post #55
gregkh wrote: post #46

Earlier quoted context omitted.

And what would that "middle ground" look like? With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?" Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just ta…

I understand that completely and i already know your thoughts on that and in some extend i do agree. Still, i think we do have in hand a very characteristic issue that even without knowing the details, simply by searching commit messages for "crypto" "key" "buffer" etc it should alert somebody to give it a second and third look.

Hell no. You can't just "guess by words."

The only thing (far!) worse than no impact marking is incomplete impact marking. That's just giving people a way to cop out, and they WILL use it.

Re: Red Hat reports security issue in Linux Kernel which was fixed 17 months prior

#60

Post by juangacovas »

bluedays wrote: post #12
mikevm wrote: post #9

I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.

Is there anyway you can use a different kernel? The kernel is really easily replaceable in other distros. I don't know much about RHEL.

I update some CentOS servers with ML kernel from ElRepo.org, and no problems for four years, but my stack could be minimalist (webservers) and do just fine
Post reply on HN