14 ms·

Meltdown and Spectre Linux kernel status

509 points by dankohn1 9y ago

gphreak 9y ago
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 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
- dustinkirkland 9y ago
  Actually, Ubuntu created the term "LTS" in 2006, for Long Term Support releases. Greg started using the term himself just a couple of years ago.
  - gphreak 9y ago
    Re-reading my post it does sound a bit confusing. What I meant is: Ubuntu LTS seems to not give a damn if the kernel they use is also an LTS release. Examples would be: 14.04, 16.04 HWE kernels, 18.04 (currently planned to be 4.15).
kazinator 9y ago
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.
- dingo_bat 9y ago
  The kernel/user enforcement by the CPU is a sham (kinda) in Intel CPUs when the data you want to access is in L1 (people are guessing). This is only for the meltdown issue. Spectre doesn't care about kernel/user at all. So even other CPUs are susceptible. Every CPU that speculates is vulnerable in theory.
proginthebox 9y ago
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.
- xroche 9y ago
  And you probably know much better than the second most important guy on linux what security means on the Internet: securing some javascript script on a random blog.
  - axiomofquality 9y ago
    HTTPS should be expected by now - ISPs keep messing with my unencrypted traffic.
    - lisper 9y ago
      Then you should get yourself a different ISP or a VPN.
      - mjal 9y ago
        Some places have no other choices for ISPs. I don't disagree that a VPN would help but that feels like it's simply dismissing that there's a problem.
      - AaronFriel 9y ago
        This is an extremely easy thing to say for many people around the world. But for a large number of people - Americans, folks in countries with monopolies or state manipulation of internet traffic - it is not. Not everyone has a different ISP to choose from. VPNs are a risky proposition and can significantly reduce bandwidth and increase latency.
        sigmar 9y ago
        Anyone that thinks ISPs don't mess with traffic, should check out this malware research https://www.virusbulletin.com/conference/vb2017/abstracts/last-minute-paper-finfisher-new-techniques-and-infection-vectors-revealed/ https://www.virusbulletin.com/conference/vb2017/abstracts/la...
Changu 9y ago
If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. I use Linux Mint and have not seen any recent kernel updates. Which kernel version is considered safe?
- tankenmate 9y ago
  Almost all Linux Mint users "piggy back" on top of the most recent Ubuntu Long Term Support (LTS) release. Currently the most recent Ubuntu LTS is 16.04 and by default it uses the 4.4 Linux kernel. There are patches for the 4.4 kernel from the kernel.org team and the Ubuntu team are testing and integrating these patches. The most recent updates from the Ubuntu team about Meltdown and Spectre is available from this URI: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
  - rand0mthought 9y ago
    So, there is NO kernel update available for Ubuntu 16.04 at this time.
    - singlow 9y ago
      Right - for desktop use though, there are Firefox and Chrome updates with mitigation. JavaScript exploits were the most dangerous desktop scenario. For servers running Ubuntu, what is the risk, as long as my services don't run arbitrary user uploaded executables? As far as I can tell it is that a different remote code execution exploit can now read the entire memory, possibly leaking secrets. Assuming we have a kernel update in the next few days, I would need to install it immediately and rotate passwords and keys. Should I revoke TLS certs? Is that paranoid?
      - chucky_z 9y ago
        I think it's naive to think you're completely protected just because code isn't supposed to ever run. It seems as though the simplest and safest piece of mind is to use some extra layers of protection ala SELinux. This won't stop the memory from being accessed, but it has a better chance of stopping things that can exploit the bug(s) in the first place. Revoking TLS certs is probably a little bit on the side of paranoia. I think you're on the right track -- just watch for the kernel update, and rotate passwords plus keys if it's not a hassle.
stefantalpalaru 9y ago
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.
fermienrico 9y ago
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?
- RedCrowbar 9y ago
  cat /proc/cpuinfo | grep pti
  - fermienrico 9y ago
    What is the expected outcome if its patched vs. not? I am getting: fpu_exception : yes
    - AbacusAvenger 9y ago
      You should see "pti" on the "flags" line of /proc/cpuinfo. You apparently don't, so you don't have page table isolation.
      - ComputerGuru 9y ago
        No, he shouldn’t be seeing that regardless as it doesn’t match the grep regex. I don’t know what, though. Edit: facepalm. Or should that be foot-in-mouth?
        sowpati 9y ago
        It does match the regex. "pti" is a substring in "exception"
        ComputerGuru 9y ago
        Thanks. I feel stupid, I looked that line up, down, and sideways for a match :/
    - ComputerGuru 9y ago
lisper 9y ago
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?
- Xylakant 9y ago
  Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.
  - lisper 9y ago
    > JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.
    - Tuna-Fish 9y ago
      JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date. If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitive or valuable data.
      - rolux 9y ago
        Keeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235 https://news.ycombinator.com/item?id=16080235
fizixer 9y ago
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.
- bonzini 9y ago
  It's closer to the second, but: 1) the vulnerability is local, not directly tied to spreading as malware (but these days placing JavaScript in an ad is easier and possibly more effective than a virus...) 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter.
  - fizixer 9y ago
    > 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter. You're missing the point. Not doubting the smartness of black hats, white hats likely took their time to discover the flaw. If you make the details public in a controlled manner and then announce the fixes shortly after, you essentially did not give black hats enough time to fill the missing pieces of the public announcement. For instance, in the extreme case, the statement "we have discovered a flaw at the hardware/CPU level in such and such chips, and we call it meltdown and spectre", it's pretty obvious the black hats would have no clue what it is. (They may have already discovered it on their own, and may have named the flaws something completely different. Even then they wouldn't know if white-hats discovered what they discovered.)
    - jacoblambda 9y ago
      unfortunately the fixes are in an open source project so even if all they knew was that there was a CPU level exploit and that specific code fixed it, black hats would still have a weaponised exploit before most people had patched their systems.
Santosh83 9y ago
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. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this machine's life? BTW, my machine is just a normal desktop/laptop, so no server stuff running or expected.
- bhauer 9y ago
  I share your concern. Based on my admittedly loose understanding, although the Spectre vulnerability is "more difficult" to exploit, I suspect it's a matter of time before exploits become more common. And the Spectre vulnerability is the one that requires a BIOS/firmware update. So that's a bit alarming for me since at least one of my several workstations is using a 5+ year old desktop board (an Intel board, ironically) that has been end-of-lifed according to its BIOS downloads support page. Meanwhile, some of the bigger server motherboard vendors (e.g., SuperMicro) are not yet prepared to supply firmware updates for recent motherboards. Recognizing that the operating system vendors/maintainers are not responsible for our systems' BIOS and hardware, the flippant advice to "talk with your device's vendor" gives me a sinking feeling. (E.g., Microsoft: "Consult with the device manufacturer about the firmware version that has the appropriate update for your CPU.") As a technical person, I am going to find it difficult to bring all of my hardware—especially the older hardware—up to snuff for coping with these vulnerabilities. I fear for people who are less technically inclined.
  - cthalupa 9y ago
    >And the Spectre vulnerability is the one that requires a BIOS/firmware update. One of the Spectre variants. The other isn't mitigated by it and will require an lfence on your sensitive areas of apps.
    - moe 9y ago
      This is a key detail that gets glossed over too much for my liking. No OS or Firmware update will fully fix Spectre. All applications that interpret untrusted code (such as Web browsers) also have to be patched. https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9 https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...
ComputerGuru 9y ago
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.
- kasabali 9y ago
  apt's kernel update process is not broken, you've just somewhat borked your system either by removing the kernel meta package or messing with repository sources/priorities. Make sure "linux-image-amd64" package is installed for Debian (and whatever equivalent package name for Ubuntu) and "apt upgrade" will install new kernel packages just fine. (And this is actually not even needed for most kernel updates in Debian because most of the time package name stays same and updated in place, package name is only changed if ABI is changed and requires recompilation of DKMS modules)
- koenigdavidmj 9y ago
  “apt full-upgrade” will upgrade everything. It may also remove packages to fix higher priority dependencies, though I’ve never seen this happen in real life.
  - ihattendorf 9y ago
    Happened to me yesterday with my Proxmox host. It wanted to install firmware-linux-free, which conflicted with pve-firmware. It decided it wanted to remove pve-firmware which would also completely remove proxmox-ve... Had to upgrade with --no-recommends.
- rhizome 9y ago
  have you tried dist-upgrade?
- antod 9y ago
  It's not supposed to install via "apt upgrade", as that command won't pull in new packages or remove packages. Unlike most, kernel packages can co exist so they are all separate packages. Thus need the extra "apt-get dist-upgrade" or "apt full-upgrade" variants as they are new dependencies.
davidw 9y ago
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.
- JdeBP 9y ago
  You do not need to read in between the lines to learn that; several commentators have come right out and said it. * http://lists.dragonflybsd.org/pipermail/users/2018-January/313758.html http://lists.dragonflybsd.org/pipermail/users/2018-January/3... (https://news.ycombinator.com/item?id=16084641 https://news.ycombinator.com/item?id=16084641) * https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5 https://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588 https://news.ycombinator.com/item?id=16075588) * http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/ http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... One of them you might have expected to use the word "fuck", but actually did not. (-: * https://lkml.org/lkml/2018/1/3/797 https://lkml.org/lkml/2018/1/3/797 (https://news.ycombinator.com/item?id=16066968 https://news.ycombinator.com/item?id=16066968) In part, this was down to the cat being let out of the bag early. * https://news.ycombinator.com/item?id=16080918 https://news.ycombinator.com/item?id=16080918 * https://news.ycombinator.com/item?id=16068510 https://news.ycombinator.com/item?id=16068510
  - arianvanp 9y ago
    If those 4 extra days of embargo would not have caused a total PR disasters on Intel's side will eat my socks. This wouldn't have become any better given another week of time.
    - fragmede 9y ago
      The fact that Intel is rumored to have know about this since June lends credence to your belief, however if that week would have let OS vendors have updates ready, and cloud providers already patched, then it would be less of a disaster. There's a certain amount of flailing about when details are released earlier than expected, and vendors don't have a answers or instructions prepared.
weinzierl 9y ago
> 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:-(
- JdeBP 9y ago
  As the Debian announcement says: * https://lists.debian.org/debian-security-announce/2018/msg00000.html https://lists.debian.org/debian-security-announce/2018/msg00... (https://news.ycombinator.com/item?id=16076175 https://news.ycombinator.com/item?id=16076175) It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-: * https://news.ycombinator.com/item?id=16076660 https://news.ycombinator.com/item?id=16076660
  - weinzierl 9y ago
    I'm not pointing at Debian. I think it is even possible to run Jessie with a current kernel, (which is quite cool) but I haven't tried it. I just upgraded all machines to Stretch and called it a day. I just did the apt-get update; apt-get upgrade dance in a hurry yesterday and thought I might be good. My post was more a reminder to everyone not be lulled into a false sense of security...
    - wazoox 9y ago
      I run (many) jessie systems with 4.9 kernels (still haven't made a 4.14 configuration). No problem at all.
      - pas 9y ago
        You might want to bite the bullet and upgrade from 4.9, because the patches for 4.9 are not so rock solid: https://news.ycombinator.com/item?id=16087736 https://news.ycombinator.com/item?id=16087736
- 9y ago
antaviana 9y ago
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.
- infogulch 9y ago
  In general, the multi-tenant security model does not rely on a malicious tenant being limited to any OS or patch (they can and always will be able to run whatever code they want including OS, and it's designed to still be secure). The cross-VM attacks we've seen actually go through the hypervisor, and since that is patched you should be fine if you're patched.
- tptacek 9y ago
  No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.
  - tedunangst 9y ago
    In theory it should be possible for a hyper visor to retrofit a fix into a guest, but it's messy and I doubt anyone will ever do it. Could be fun though. Quick sketch: disable EPT and go back to shadow paging. Maintain a third page table with any kernel pages unmapped. Invisibly swap between on syscalls.
    - wolf550e 9y ago
      This sounds really slow to me. What is the overhead of "disable EPT and go back to shadow paging", or what was the performance win of EPT?
api 9y ago
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.
_nalply 9y ago
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?
- JdeBP 9y ago
  Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions. * https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... (https://news.ycombinator.com/item?id=16080002 https://news.ycombinator.com/item?id=16080002) * https://dev.to/isaacandsuch/how-meltdown-works-28j2 https://dev.to/isaacandsuch/how-meltdown-works-28j2 (https://news.ycombinator.com/item?id=16085592 https://news.ycombinator.com/item?id=16085592) One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. * https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910 https://news.ycombinator.com/item?id=16079910)
  - jancsika 9y ago
    > One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. But to read the data one still must use timing attacks, no?
nvus 9y ago
A good way Intel could say sorry is to have a new generation hardened cpus at a good price.
- pas 9y ago
  Even offering ECC for mere mortals would be a good start. Of course with the option to disable as much of the ME as possible.
codys 9y ago
> 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.
- pkilgore 9y ago
  I'll eat my hat if it isn't some version of "here is a giant patch set we never worked through the chain nor asked about at all please make it your problem to mainline it immediately, followed by, well, a good old fashioned LKML go fsck yourself."
alibert 9y ago
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)
- tptacek 9y ago
  It's a good first comment. Generally: as long as you're not being deliberately mean or derisive, you're doing fine by the guidelines. Welcome!
  - rando-1221 9y ago
    The derisive comment is really precious coming from you.
- e12e 9y ago
  Kernel ml is public - embargoed/sensitive issues are typically disclosed on closed lists - and discussed internally. RedHat does have many devs that work on the kernel, as does other distros. Typically, a sensitive issue will be disclosed privately, and devs for various groups will share progress privately. Then ideally, all distros will have patches and documentation ready on the agreed date of public disclosure. See: http://oss-security.openwall.org/wiki/mailing-lists/distros http://oss-security.openwall.org/wiki/mailing-lists/distros
- pkaye 9y ago
  The bug was disclosed to various organizations in early november so work was going for some time. And yes, Red Hat makes significant contributions to the Linux kernel. Red Hat maintains their own version of the kernel and integrating those changes back to the mainstream version can take time to reach consensus.
BuuQu9hu 9y ago
Hello, 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 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? Thanks.
bertolo1988 9y ago
What about Ubuntu users? Is the update our already?
- cheeseprocedure 9y ago
  Not yet - keep an eye on their wiki page for Meltdown/Spectre: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
deleted 9y ago
[deleted]
Bitcoin_McPonzi 9y ago
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).
amluto 9y ago
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.
- lima 9y ago
  As far as I can tell, the RHEL/CentOS kernel has mitigations not only for Meltdown but also Spectre (using the new MSRs). Am I right in assuming that Red Hat built their own mitigations, independently from upstream?
  - amluto 9y ago
    It seems like a smallish consortium of poorly coordinated developers built the Spectre mitigation patches. Upstream wasn't involved until a couple days ago.
  - unixsurfer 9y ago
    The patches on RedHat 7.4 have impact on performance and capacity for a Load Balancer type of workload, see https://www.spinics.net/lists/stable/msg209193.html https://www.spinics.net/lists/stable/msg209193.html
danjoc 9y ago
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.
blockoperation 9y ago
What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. 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. [1] https://tracker.debian.org/news/899110 https://tracker.debian.org/news/899110 [2] https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File https://downloadcenter.intel.com/download/27337/Linux-Proces...
- blockoperation 9y ago
  Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes. I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]). [1] https://patchwork.kernel.org/patch/10147547/ https://patchwork.kernel.org/patch/10147547/
throhaway2018 9y ago
Is the clock still ticking on Joyent.com patching their public cloud (illumos, SmartOS)? https://help.joyent.com/hc/en-us/articles/115015938847-Security-Advisory-Intel-Security-Findings https://help.joyent.com/hc/en-us/articles/115015938847-Secur...

509 points by dankohn1 9y ago

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 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

dustinkirkland 9y ago
Actually, Ubuntu created the term "LTS" in 2006, for Long Term Support releases. Greg started using the term himself just a couple of years ago.
- gphreak 9y ago
  Re-reading my post it does sound a bit confusing. What I meant is: Ubuntu LTS seems to not give a damn if the kernel they use is also an LTS release. Examples would be: 14.04, 16.04 HWE kernels, 18.04 (currently planned to be 4.15).

kazinator 9y ago

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.

dingo_bat 9y ago
The kernel/user enforcement by the CPU is a sham (kinda) in Intel CPUs when the data you want to access is in L1 (people are guessing). This is only for the meltdown issue. Spectre doesn't care about kernel/user at all. So even other CPUs are susceptible. Every CPU that speculates is vulnerable in theory.

proginthebox 9y ago

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.

xroche 9y ago
And you probably know much better than the second most important guy on linux what security means on the Internet: securing some javascript script on a random blog.
- axiomofquality 9y ago
  HTTPS should be expected by now - ISPs keep messing with my unencrypted traffic.
  - lisper 9y ago
    Then you should get yourself a different ISP or a VPN.
    - mjal 9y ago
      Some places have no other choices for ISPs. I don't disagree that a VPN would help but that feels like it's simply dismissing that there's a problem.
    - AaronFriel 9y ago
      This is an extremely easy thing to say for many people around the world. But for a large number of people - Americans, folks in countries with monopolies or state manipulation of internet traffic - it is not. Not everyone has a different ISP to choose from. VPNs are a risky proposition and can significantly reduce bandwidth and increase latency.
      - sigmar 9y ago
        Anyone that thinks ISPs don't mess with traffic, should check out this malware research https://www.virusbulletin.com/conference/vb2017/abstracts/last-minute-paper-finfisher-new-techniques-and-infection-vectors-revealed/ https://www.virusbulletin.com/conference/vb2017/abstracts/la...

Changu 9y ago

If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. I use Linux Mint and have not seen any recent kernel updates. Which kernel version is considered safe?

tankenmate 9y ago
Almost all Linux Mint users "piggy back" on top of the most recent Ubuntu Long Term Support (LTS) release. Currently the most recent Ubuntu LTS is 16.04 and by default it uses the 4.4 Linux kernel. There are patches for the 4.4 kernel from the kernel.org team and the Ubuntu team are testing and integrating these patches. The most recent updates from the Ubuntu team about Meltdown and Spectre is available from this URI: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
- rand0mthought 9y ago
  So, there is NO kernel update available for Ubuntu 16.04 at this time.
  - singlow 9y ago
    Right - for desktop use though, there are Firefox and Chrome updates with mitigation. JavaScript exploits were the most dangerous desktop scenario. For servers running Ubuntu, what is the risk, as long as my services don't run arbitrary user uploaded executables? As far as I can tell it is that a different remote code execution exploit can now read the entire memory, possibly leaking secrets. Assuming we have a kernel update in the next few days, I would need to install it immediately and rotate passwords and keys. Should I revoke TLS certs? Is that paranoid?
    - chucky_z 9y ago
      I think it's naive to think you're completely protected just because code isn't supposed to ever run. It seems as though the simplest and safest piece of mind is to use some extra layers of protection ala SELinux. This won't stop the memory from being accessed, but it has a better chance of stopping things that can exploit the bug(s) in the first place. Revoking TLS certs is probably a little bit on the side of paranoia. I think you're on the right track -- just watch for the kernel update, and rotate passwords plus keys if it's not a hassle.

stefantalpalaru 9y ago

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.

fermienrico 9y ago

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?

RedCrowbar 9y ago
cat /proc/cpuinfo | grep pti
- fermienrico 9y ago
  What is the expected outcome if its patched vs. not? I am getting: fpu_exception : yes
  - AbacusAvenger 9y ago
    You should see "pti" on the "flags" line of /proc/cpuinfo. You apparently don't, so you don't have page table isolation.
    - ComputerGuru 9y ago
      No, he shouldn’t be seeing that regardless as it doesn’t match the grep regex. I don’t know what, though. Edit: facepalm. Or should that be foot-in-mouth?
      - sowpati 9y ago
        It does match the regex. "pti" is a substring in "exception"
        ComputerGuru 9y ago
        Thanks. I feel stupid, I looked that line up, down, and sideways for a match :/
  - ComputerGuru 9y ago

lisper 9y ago

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?

Xylakant 9y ago
Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.
- lisper 9y ago
  > JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.
  - Tuna-Fish 9y ago
    JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date. If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitive or valuable data.
    - rolux 9y ago
      Keeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235 https://news.ycombinator.com/item?id=16080235

fizixer 9y ago

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.

bonzini 9y ago
It's closer to the second, but: 1) the vulnerability is local, not directly tied to spreading as malware (but these days placing JavaScript in an ad is easier and possibly more effective than a virus...) 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter.
- fizixer 9y ago
  > 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter. You're missing the point. Not doubting the smartness of black hats, white hats likely took their time to discover the flaw. If you make the details public in a controlled manner and then announce the fixes shortly after, you essentially did not give black hats enough time to fill the missing pieces of the public announcement. For instance, in the extreme case, the statement "we have discovered a flaw at the hardware/CPU level in such and such chips, and we call it meltdown and spectre", it's pretty obvious the black hats would have no clue what it is. (They may have already discovered it on their own, and may have named the flaws something completely different. Even then they wouldn't know if white-hats discovered what they discovered.)
  - jacoblambda 9y ago
    unfortunately the fixes are in an open source project so even if all they knew was that there was a CPU level exploit and that specific code fixed it, black hats would still have a weaponised exploit before most people had patched their systems.

Santosh83 9y ago

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. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this machine's life? BTW, my machine is just a normal desktop/laptop, so no server stuff running or expected.

bhauer 9y ago
I share your concern. Based on my admittedly loose understanding, although the Spectre vulnerability is "more difficult" to exploit, I suspect it's a matter of time before exploits become more common. And the Spectre vulnerability is the one that requires a BIOS/firmware update. So that's a bit alarming for me since at least one of my several workstations is using a 5+ year old desktop board (an Intel board, ironically) that has been end-of-lifed according to its BIOS downloads support page. Meanwhile, some of the bigger server motherboard vendors (e.g., SuperMicro) are not yet prepared to supply firmware updates for recent motherboards. Recognizing that the operating system vendors/maintainers are not responsible for our systems' BIOS and hardware, the flippant advice to "talk with your device's vendor" gives me a sinking feeling. (E.g., Microsoft: "Consult with the device manufacturer about the firmware version that has the appropriate update for your CPU.") As a technical person, I am going to find it difficult to bring all of my hardware—especially the older hardware—up to snuff for coping with these vulnerabilities. I fear for people who are less technically inclined.
- cthalupa 9y ago
  >And the Spectre vulnerability is the one that requires a BIOS/firmware update. One of the Spectre variants. The other isn't mitigated by it and will require an lfence on your sensitive areas of apps.
  - moe 9y ago
    This is a key detail that gets glossed over too much for my liking. No OS or Firmware update will fully fix Spectre. All applications that interpret untrusted code (such as Web browsers) also have to be patched. https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9 https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...

ComputerGuru 9y ago

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.

kasabali 9y ago
apt's kernel update process is not broken, you've just somewhat borked your system either by removing the kernel meta package or messing with repository sources/priorities. Make sure "linux-image-amd64" package is installed for Debian (and whatever equivalent package name for Ubuntu) and "apt upgrade" will install new kernel packages just fine. (And this is actually not even needed for most kernel updates in Debian because most of the time package name stays same and updated in place, package name is only changed if ABI is changed and requires recompilation of DKMS modules)
koenigdavidmj 9y ago
“apt full-upgrade” will upgrade everything. It may also remove packages to fix higher priority dependencies, though I’ve never seen this happen in real life.
- ihattendorf 9y ago
  Happened to me yesterday with my Proxmox host. It wanted to install firmware-linux-free, which conflicted with pve-firmware. It decided it wanted to remove pve-firmware which would also completely remove proxmox-ve... Had to upgrade with --no-recommends.
rhizome 9y ago
have you tried dist-upgrade?
antod 9y ago
It's not supposed to install via "apt upgrade", as that command won't pull in new packages or remove packages. Unlike most, kernel packages can co exist so they are all separate packages. Thus need the extra "apt-get dist-upgrade" or "apt full-upgrade" variants as they are new dependencies.

davidw 9y ago

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.

JdeBP 9y ago
You do not need to read in between the lines to learn that; several commentators have come right out and said it. * http://lists.dragonflybsd.org/pipermail/users/2018-January/313758.html http://lists.dragonflybsd.org/pipermail/users/2018-January/3... (https://news.ycombinator.com/item?id=16084641 https://news.ycombinator.com/item?id=16084641) * https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5 https://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588 https://news.ycombinator.com/item?id=16075588) * http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/ http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... One of them you might have expected to use the word "fuck", but actually did not. (-: * https://lkml.org/lkml/2018/1/3/797 https://lkml.org/lkml/2018/1/3/797 (https://news.ycombinator.com/item?id=16066968 https://news.ycombinator.com/item?id=16066968) In part, this was down to the cat being let out of the bag early. * https://news.ycombinator.com/item?id=16080918 https://news.ycombinator.com/item?id=16080918 * https://news.ycombinator.com/item?id=16068510 https://news.ycombinator.com/item?id=16068510
- arianvanp 9y ago
  If those 4 extra days of embargo would not have caused a total PR disasters on Intel's side will eat my socks. This wouldn't have become any better given another week of time.
  - fragmede 9y ago
    The fact that Intel is rumored to have know about this since June lends credence to your belief, however if that week would have let OS vendors have updates ready, and cloud providers already patched, then it would be less of a disaster. There's a certain amount of flailing about when details are released earlier than expected, and vendors don't have a answers or instructions prepared.

weinzierl 9y ago

> 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:-(

JdeBP 9y ago
As the Debian announcement says: * https://lists.debian.org/debian-security-announce/2018/msg00000.html https://lists.debian.org/debian-security-announce/2018/msg00... (https://news.ycombinator.com/item?id=16076175 https://news.ycombinator.com/item?id=16076175) It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-: * https://news.ycombinator.com/item?id=16076660 https://news.ycombinator.com/item?id=16076660
- weinzierl 9y ago
  I'm not pointing at Debian. I think it is even possible to run Jessie with a current kernel, (which is quite cool) but I haven't tried it. I just upgraded all machines to Stretch and called it a day. I just did the apt-get update; apt-get upgrade dance in a hurry yesterday and thought I might be good. My post was more a reminder to everyone not be lulled into a false sense of security...
  - wazoox 9y ago
    I run (many) jessie systems with 4.9 kernels (still haven't made a 4.14 configuration). No problem at all.
    - pas 9y ago
      You might want to bite the bullet and upgrade from 4.9, because the patches for 4.9 are not so rock solid: https://news.ycombinator.com/item?id=16087736 https://news.ycombinator.com/item?id=16087736
9y ago

antaviana 9y ago

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.

infogulch 9y ago
In general, the multi-tenant security model does not rely on a malicious tenant being limited to any OS or patch (they can and always will be able to run whatever code they want including OS, and it's designed to still be secure). The cross-VM attacks we've seen actually go through the hypervisor, and since that is patched you should be fine if you're patched.
tptacek 9y ago
No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.
- tedunangst 9y ago
  In theory it should be possible for a hyper visor to retrofit a fix into a guest, but it's messy and I doubt anyone will ever do it. Could be fun though. Quick sketch: disable EPT and go back to shadow paging. Maintain a third page table with any kernel pages unmapped. Invisibly swap between on syscalls.
  - wolf550e 9y ago
    This sounds really slow to me. What is the overhead of "disable EPT and go back to shadow paging", or what was the performance win of EPT?

api 9y ago

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.

_nalply 9y ago

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?

JdeBP 9y ago
Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions. * https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... (https://news.ycombinator.com/item?id=16080002 https://news.ycombinator.com/item?id=16080002) * https://dev.to/isaacandsuch/how-meltdown-works-28j2 https://dev.to/isaacandsuch/how-meltdown-works-28j2 (https://news.ycombinator.com/item?id=16085592 https://news.ycombinator.com/item?id=16085592) One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. * https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910 https://news.ycombinator.com/item?id=16079910)
- jancsika 9y ago
  > One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing. But to read the data one still must use timing attacks, no?

nvus 9y ago

A good way Intel could say sorry is to have a new generation hardened cpus at a good price.

pas 9y ago
Even offering ECC for mere mortals would be a good start. Of course with the option to disable as much of the ME as possible.

codys 9y ago

> 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.

pkilgore 9y ago
I'll eat my hat if it isn't some version of "here is a giant patch set we never worked through the chain nor asked about at all please make it your problem to mainline it immediately, followed by, well, a good old fashioned LKML go fsck yourself."

alibert 9y ago

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)

tptacek 9y ago
It's a good first comment. Generally: as long as you're not being deliberately mean or derisive, you're doing fine by the guidelines. Welcome!
- rando-1221 9y ago
  The derisive comment is really precious coming from you.
e12e 9y ago
Kernel ml is public - embargoed/sensitive issues are typically disclosed on closed lists - and discussed internally. RedHat does have many devs that work on the kernel, as does other distros. Typically, a sensitive issue will be disclosed privately, and devs for various groups will share progress privately. Then ideally, all distros will have patches and documentation ready on the agreed date of public disclosure. See: http://oss-security.openwall.org/wiki/mailing-lists/distros http://oss-security.openwall.org/wiki/mailing-lists/distros
pkaye 9y ago
The bug was disclosed to various organizations in early november so work was going for some time. And yes, Red Hat makes significant contributions to the Linux kernel. Red Hat maintains their own version of the kernel and integrating those changes back to the mainstream version can take time to reach consensus.

BuuQu9hu 9y ago

Hello, 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 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? Thanks.

bertolo1988 9y ago

What about Ubuntu users? Is the update our already?

cheeseprocedure 9y ago
Not yet - keep an eye on their wiki page for Meltdown/Spectre: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...

deleted 9y ago

[deleted]

Bitcoin_McPonzi 9y ago

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).

amluto 9y ago

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.

lima 9y ago
As far as I can tell, the RHEL/CentOS kernel has mitigations not only for Meltdown but also Spectre (using the new MSRs). Am I right in assuming that Red Hat built their own mitigations, independently from upstream?
- amluto 9y ago
  It seems like a smallish consortium of poorly coordinated developers built the Spectre mitigation patches. Upstream wasn't involved until a couple days ago.
- unixsurfer 9y ago
  The patches on RedHat 7.4 have impact on performance and capacity for a Load Balancer type of workload, see https://www.spinics.net/lists/stable/msg209193.html https://www.spinics.net/lists/stable/msg209193.html

danjoc 9y ago

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.

blockoperation 9y ago

What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. 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. [1] https://tracker.debian.org/news/899110 https://tracker.debian.org/news/899110 [2] https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File https://downloadcenter.intel.com/download/27337/Linux-Proces...

blockoperation 9y ago
Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes. I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]). [1] https://patchwork.kernel.org/patch/10147547/ https://patchwork.kernel.org/patch/10147547/

throhaway2018 9y ago

Is the clock still ticking on Joyent.com patching their public cloud (illumos, SmartOS)? https://help.joyent.com/hc/en-us/articles/115015938847-Security-Advisory-Intel-Security-Findings https://help.joyent.com/hc/en-us/articles/115015938847-Secur...