91–100 of 127 posts
Earlier quoted context omitted.
The changes are all upstream to begin with. It's a fork in the sense that it's heavily diverged from the source of the old kernel, but it's all still backports and not a ton of new development.
Why does it need to be diverged if there is no new functionality in their version? Because they can?
Earlier quoted context omitted.
> We can't really get rid of speculative execution Why not? > but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".
Your last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do). It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them i…
Earlier quoted context omitted.
RHEL kernels are heavily patched, i.e. stuff gets backported from new kernels, sometimes even from -rc if needed. The version number is therefore not that useful. Some call it a Frankenkernel. :)
The nice thing is that it's all fully documented. If you download the kernel src.rpm[1] and install it, you'll get the kernel RPM spec file in your default RPM build environment paths (or use rpm2cpio $KERNEL_SRPM | cpio -idmv). The way the RPM building works is to take a vanilla kernel and then apply a LOT of individual patch files to it, each with their own entry. Well, at least that's how it was a long time ago wh…
Earlier quoted context omitted.
> Here's how that works: Thank about Haskell, or another purely-functional language. An attacker provides you with a pure function to execute. Because it's a pure function, for some given set of inputs, it will always produce exactly the same output, no matter what machine you run it on, or what else is going on in the background. Therefore, the output cannot possibly incorporate observations from side channels, no m…
If the attacker can do timing on their side in a pure function, then by definition the time the response takes is one of the function inputs.
Earlier quoted context omitted.
The changes are all upstream to begin with. It's a fork in the sense that it's heavily diverged from the source of the old kernel, but it's all still backports and not a ton of new development.
Why does it need to be diverged if there is no new functionality in their version? Because they can?
Andy Lutomirski noted on another thread that he unintentionally fixed this two years ago in Linux: https://news.ycombinator.com/item?id=17304947 (He switched it to eager FP because it's faster on modern hardware.) But a lot of people running old LTS kernels may be affected. EDIT: Looks like Luto's change landed in kernel version 4.6. https://kernelnewbies.org/Linux_4.6#List_of_merges https://git.kernel.org/pub/scm/li…
Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.
This is very wrong.
It would be trivial for Red Hat to update the kernel shipped into RHEL. It's not a question that they "can't keep up".
What they are doing is much more difficult and takes much more effort. They are backporting all security fixes, and sometimes other features from newer kernels to older kernels. Why? Because many RHEL customers want older kernels. Unlike Windows and Solaris, Linux doesn't have a stable kernel ABI (by design). Some RHEL customers want to use binary drivers, and they want their drivers to work when they update their system. Some other RHEL customers do not use or need binary drivers, but they do want to avoid possible incompatibility problems introduced by newer kernels. And no, it doesn't matter that the kernel API is very stable. Sometimes even fixing bugs can introduce incompatibility problems in badly written software. Other times something like changing some trivial subtle thing about the scheduler can make a badly written program perform much differently then it used to be. The world is full of such programs, and people who administer such systems are very grateful the behavior of their systems doesn't randomly change across the lifetime of a release.
The fact that RHEL freezes the versions of shipped software is its greatest feature. It's not for everyone, but it's for some people, and for those people it is very important.
Earlier quoted context omitted.
I'm using HP B120i fakeraid controller with proprietary driver and it broke after 7.4 upgrade, so while they probably doing a good job about binary compatibility (7.5 didn't broke it), it's not ideal.
Unfortunately the kABI does not encompass every symbol exported by the kernel, there is a whitelist maintained in the kernel-abi-whitelists package and scripts to check conformance of a module to the whitelist. Symbols are only ever added throughout the lifecycle of a RHEL release, so anything that conforms to the 7.3 kABI will also work on 7.4 - but if the module uses a symbol NOT whitelisted in 7.3 there's no guara…
I posted some details about this to Twitter: https://twitter.com/cperciva/status/1007010583244230656
Earlier quoted context omitted.
Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.
> I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds. This is very wrong. It would be trivial for Red Hat to update the kernel shipped into RHEL. It's not a question that they "can't keep up". What they are doing is much more difficult and takes much more effort. They are backporting all security fixes, and sometimes other features from newer kernels to older ker…
Like changing the scheduler preferences of which process runs first on fork(), the parent or the child, exposed a bug in bash: https://yarchive.net/comp/linux/child-runs-first.html
Earlier quoted context omitted.
Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.
> I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds. This is very wrong. It would be trivial for Red Hat to update the kernel shipped into RHEL. It's not a question that they "can't keep up". What they are doing is much more difficult and takes much more effort. They are backporting all security fixes, and sometimes other features from newer kernels to older ker…