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).
Meltdown and Spectre Linux kernel status
131–140 of 186 posts
Re: Meltdown and Spectre Linux kernel status
#132One 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.
Re: Meltdown and Spectre Linux kernel status
#133Earlier quoted context omitted.
The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…
AFAIK on Intel it's not possible to load a microcode update over the top of one already loaded by your firmware, so if the firmware shipped an older update, the firmware really needs to be updated. (Please someone correct me if this isn't the case -- I can't even remember where I read this)
Nope, the OS or hypervisor (but not a guest) can freely update whenever they like, as long as all the updates are to newer versions. For updates that modify visible CPU features, like these, it's helpful to apply them before boot. Linux has a mechanism to apply "early" updates from initramfs that effectively function before the kernel boots. I don't think other OSes can do that.
Re: Meltdown and Spectre Linux kernel status
#134Earlier quoted context omitted.
> These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential disclosure. In this particular case, most of the fix had to be done in the operating system (the new microcode only enabled extra functionality needed by part of the operating system fixes), so it makes sense that operating system developers were allowed (and required) to prepare in advance. Th…
Ubuntu and BSD still have no fixes. It indeed seems like a preferrential disclosure. Plus no 2nd-tier cloud providers like DO were notified.
Canonical said they were told in November.
Re: Meltdown and Spectre Linux kernel status
#135The 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.
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.
Given that Javascript is a known attack vector for the very bugs he's talking about, yes apparently he does know better.
Re: Meltdown and Spectre Linux kernel status
#136Earlier quoted context omitted.
Reading between the lines would be figuring out who at or around Intel profits from this chaos. There is certainly someone, but since everybody is just focussed on the technical issues, whoever it is will probably throw a party this weekend.
No, one does not need to read in between the lines for that, either. One can simply read the lines. Far from everyone being "just focussed on the technical issues", the questions over the share dealings have made the news in the papers, from The Australian to The Irish Times .
Insider trading happens all the time. But usually you don't read about it in the news. So that the Intel CEO's insider trading got him in trouble shows there's someone fighting against him. Thus, no that's not the full story. I know it's hard to accept but the official scape goat is rarely the trouble maker. Or do you believe that the 2008 crisis was just the doing of that one banker that got jailed?
Re: Meltdown and Spectre Linux kernel status
#137Earlier quoted context omitted.
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.
> JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.
Yeah, it's possible to use to bypass same origin policy and read data across origins. Basic idea is that most browsers have multiple origins in the same process, meaning that the same speculative execution + optimistic caching can leak data to js from another origin in the same process.
Re: Meltdown and Spectre Linux kernel status
#138What 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…
The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…
VMware distributes a driver[1] one can install to patch the microcode on Windows at runtime. If these updates need to be recognized before OS boot, this may not mitigate the dangers. But in my test lab, HWiNFO64 shows the current microcode version.
The Intel[2] and AMD[3] microcode can be downloaded but I can't vouch for how many Meltdown/Spectre mitigations these versions contain. The Intel one is dated 2017-11-17.
[1] https://labs.vmware.com/flings/vmware-cpu-microcode-update-d...
[2] https://downloadcenter.intel.com/download/27337/Linux-Proces...
[3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
Re: Meltdown and Spectre Linux kernel status
#139Earlier quoted context omitted.
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, ironical…
>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.
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/2f86755260f2fee1baf71c90cd653...
Re: Meltdown and Spectre Linux kernel status
#140Earlier quoted context omitted.
> These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential disclosure. In this particular case, most of the fix had to be done in the operating system (the new microcode only enabled extra functionality needed by part of the operating system fixes), so it makes sense that operating system developers were allowed (and required) to prepare in advance. Th…
Ubuntu and BSD still have no fixes. It indeed seems like a preferrential disclosure. Plus no 2nd-tier cloud providers like DO were notified.
It will be pretty unfortunate if it turns out that the projects that maintain a kernel (FreeBSD, various others) only received notification at Christmas, while various Linux distros (who have to deal with packaging, release, QA but not developing their own kernel patch since that comes from upstream) got a long warning period. It seems that way... Looking forward to reading about how this played out when the dust settles.