One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences.
1. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x86 changes need to be backported, it'll be a huge mess.
2. There is only minimal upstream support. I, for example, am already largely ignoring two bugs in the backports that aren't in the upstream version. Why? Because I have no affiliation with a distro using an old kernel.
3. Contrary to its marketing, KAISER does not effectively mitigate the old kASLR leaks. PTI very nearly does, and I intend to improve it further once I find some time to do so. I doubt those improvements will get backported to pre-4.14 kernels.
4. At least some versions of "KAISER", on meltdown-affected hardware, expose the kernel stack to userspace. If that's not usable for rooting a box, I'll eat my hat. KPTI doesn't have this problem.
If you can put pressure on your organization or suppliers to update to 4.14 or better, please do so. Red Hat, especially, should seriously consider moving to 4.14 for RHEL 8.
FYI, Red Hat (and CentOS) already have updated kernels with mitigation.
And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day?
I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, preliminary performance test, etc. without having already patches implemented and tested for some time.
Do they have internal kernel devs? And so, do Redhat have another implementation?
(This is my first comment on HN, I hope I'm following adequately the guidelines)
> As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually
I'm looking forward to that story.
What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model.
BTW, my machine is just a normal desktop/laptop, so no server stuff running or expected.
I use AWS instances (multi-tenant). I understand that by now AWS hypervisors have been patched.
Does that fully protect my unpatched AWS instances from this CPU-level issues?
If not, is there any way to protect my AWS instance from a rogue unpatched attacker instance running on the same hypervisor?
In other words, with the current CPUs deployed at AWS, will it be possible for an attacker to simply launch an unpatched instance to steal data from other instances (patched or not) running on the same AWS hypervisor?
I hope not, because the cloud multi-tenant model would be effectively dead until AWS hosts with unaffected CPUs are available.
What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there, but Intel's own package has yet to be updated. The 20171215 update carried by some distros only seems to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed, are they covered by the 20171117 update, or are the new microcodes simply not ready for all models yet?
Of course, the microcode updates are meaningless without the corresponding kernel patches, but apparently only RHEL and SLES were deemed worthy of receiving those ahead of time, having already rolled them out while Linus and co are left scrambling to integrate the IBRS and retpoline code dumps after the fact.
Reading between the lines, it seems this is a pretty colossal fuckup by Intel; both in terms of the bug but especially how it was handled.
From my cursory reading I understand it is a cleverly orchestrated timing attack.
In other words, if something would need 500 picoseconds you have bit 1, if it is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air).
This is made possible because processors execute the read speculatively even if it is actually forbidden. This read causes a cache hit. Of course the read is never brought into effect because first it is forbidden and second it is in a branch which will never be executed. At the time of the speculative read the CPU seems not to have enough information to know not to execute that read. Even speculatively.
And that speculative read has a side effect on the cache which is measured by the exploit.
Of course the read is never made visible to the process because later the CPU knows not to bring it into effect. However then it is too late: there is measurable difference in caching times.
Did I understand the way of the attack correctly?
> If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck.
So, if you are running a (still supported) Debian Jessie a simple apt-get upgrade isn't gonna cut it:-(
Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?
With so much going on - is there a way in linux to know whether my system is patched or not?
Similar to the powershell script for Windows?
Based on the remarks I'm wondering if there's a distribution out there that is similar to Ubuntu LTS but only uses LTS kernels.
I'm on CentOS right now and love it, but from what I've understand so far it would be preferable to be on a newer kernel.
I was planning to look at Ubuntu LTS and while they do have updated kernels available they seem to ignore LTS: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
Also, 18.04 will be based on 4.15 which doesn't make sense to me.
Debian stable maybe?
EDIT: I know I can install updated kernels but I'd rather stick with what a core distribution provides if possible
We applies it to the bare metal DB servers for my.zerotier.com and there is definitely a detectable increase in IO cost. Reducing syscall overhead is going to become even more important.
What about Ubuntu users? Is the update our already?
I've been thinking about some of this. A possible design to prevent some of these issues would be to read all protected memory, in speculative execution paths, as dummy all-zero bits value, and not put anything into the cache. I.e. no actual access takes place to any protected area and no breadcrumbs are left in any CPU storage such as a cache. (Then if that path is actually taken, generate the exception).
The whole problem is that the kernel/user protection is just a sham that is not being taken seriously by the CPU implementation. It allows access to take place without a proper mode change. Basically the whole fetch-decode-execute machinery (all of its pipelines, caches, registers and other areeas) should be regarded as untrusted and prevented from accessing or storing anything unauthorized according to the current security state of the CPU.
Is the clock still ticking on Joyent.com patching their public cloud (illumos, SmartOS)?
I use Linux Mint and have not seen any recent kernel updates.
If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already.
Which kernel version is considered safe?
A good way Intel could say sorry is to have a new generation hardened cpus at a good price.
So if you're running a ARM64 chromebook, the answer appears to be: get fukt.
"For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged into them, due to the large number of prerequisite patches required. All of those prerequisite patches have been long merged and tested in the android-common kernels, so I think it is a better idea to just rely on those kernel branches instead of the LTS release for ARM systems at this point in time."
Great. Into the trash it goes.
This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.
The website serves JS and does not serve it over https, and discusses Spectre bug and how to patch it. I know he is the second most important guy on linux, but the irony.
Why is there no mention of other CPU vendors besides ARM? You'd think it's pretty important that the Meltdown patches are only needed on Intel CPUs.
As far s I can tell, "Linux" (and MacOS) are especially vulnerable because each process maps in the entire kernel. This isn't true for more modern and microkernel OSs (Including Windows 10).
I'm not a tech expert at all, could you give an info please?
I've run this test and it's positive : https://repl.it/repls/DeliriousGreenOxpecker
Does it mean that a website with this kind of script can access all of my browser session? For instance, if I log in to my bank account, then I logout and about 10 minutes after I visit an evil website. Could evil website retrieve the URL of my bank account + the credentials?
Also, is there a POC that can display all browser history?
I'm out of the loop but I heard it's the white hat hackers who exposed the flaw (probably they were at Google?).
Is the exposition carefully publicized so the flaw is not exploitable by malicious hackers?
Or does Project Zero expose everything, and a malicious hacker can read it and create code that spreads over the internet to harm computers?
I hope it's not the second case because that should cause global panic.