LWN: Comments on "A collection of Meltdown/Spectre postings"

Xen FAQ

sampablokuper — Fri, 02 Feb 2018 13:14:40 +0000

> no-one should trust these forthcoming microcode updates not to make their host systems *less* secure.

> Unless, that is, Intel and AMD break with recent traditions and make the microcode updates' contents open for public scrutiny and security auditing.

> I'm not holding my breath.

Bunnie Huang (as is so often the case) puts it well:

"Instead of suing Intel for money, what if we sue Intel for documentation? If documentation and transparency have real value, then this is a chance to finally put that value in economic terms that Intel shareholders can understand. I propose a bargain somewhere along these lines: if Intel releases comprehensive microarchitectural hardware design specifications, microcode, firmware, and all software source code (e.g. for AMT/ME) so that the community can band together to hammer out any other security bugs hiding in their hardware, then Intel is absolved of any payouts related to the Spectre/Meltdown exploits."

Sounds good to me.

A collection of Meltdown/Spectre postings

pabs — Fri, 12 Jan 2018 03:22:54 +0000

https://raw.githubusercontent.com/QubesOS/qubes-secpack/m...

A collection of Meltdown/Spectre postings

pabs — Fri, 12 Jan 2018 02:48:00 +0000

https://wingolog.org/archives/2018/01/11/spectre-and-the-...

A collection of Meltdown/Spectre postings

tcarrez — Thu, 11 Jan 2018 12:55:09 +0000

General guidance for OpenStack providers and users:
https://ttx.re/openstack-spectre-meltdown-faq.html

A collection of Meltdown/Spectre postings

mariuz — Wed, 10 Jan 2018 14:22:21 +0000

In a recent post to firebird-devel list, an user reported that the performance of the Firebird server dropped ~30% after he upgraded its Linux kernel to a version that fixed some of the issues

https://sourceforge.net/p/firebird/mailman/message/36183029/

A collection of Meltdown/Spectre postings

rsidd — Mon, 08 Jan 2018 10:09:09 +0000

The link is to an archived LKML post -- not exactly a quote from LWN :)

A detection tool or even a monitoring plugin would be nice

sampablokuper — Sun, 07 Jan 2018 22:53:25 +0000

> The second issue is called Meltdown. This is the one that apparently caused the Intel CEO to sell as much of his Intel stock as the company allowed.

The stock sale was covered here a few weeks after it occurred: https://www.fool.com/investing/2017/12/19/intels-ceo-just...

AFAIK, no-one has been able to definitively confirm that Brian Krzanich sold the stock due to insider knowledge about Meltdown or Spectre.

Even so, it doesn't look good that Krzanich sold *as much stock as was contractually allowable* after being (presumably) briefed on these serious, not-yet-publicly-known flaws in Intel products.

Perhaps he was getting investment advice from John Gamble? https://www.bloomberg.com/news/articles/2017-09-07/three-...

A collection of Meltdown/Spectre postings

dtlin — Sun, 07 Jan 2018 00:44:12 +0000

And assuming I haven't misunderstood things, any shared library that could be loaded into a sensitive process should also be compiled with -z retpolineplt, which potentially impacts most of the desktop.

A collection of Meltdown/Spectre postings

dtlin — Sun, 07 Jan 2018 00:39:10 +0000

As I understand it, any program whose execution can be influenced by outside code is at risk. Maybe somebody will figure out how to tickle the X server or compositor to go down specific code paths from a browser, and from that read out your keyboard buffer or display...

A detection tool or even a monitoring plugin would be nice

ras — Sat, 06 Jan 2018 23:28:21 +0000

> only needs to run very tightly restricted code in the target process,
> in the form of eBPF (either JITted or not),

eBPF is same situation has JavaScript, and the latter is far worse IMO. They can restrict eBPF as much as necessary to mitigate the problem, right up to insisting only trusted users can load it so it is no longer "untrusted code". Browsers don't have that option with JavaScript.

> but anything that can be manipulated to perform a similar sequence of
> operations (safely bounds-checked memory read then a dependent read)
> should be similarly vulnerable, which could include lots of APIs that
> don't involve code-like input at all.

The required code is a speculative read of the form:

array[*target_byte << 4096]

at best. This requires the external program to not only somehow arrange for the speculative read to be executed, but also into inject target_byte somehow. In the paper they say they looked at lots of programs to find one that happened to execute the right sequence occasionally, but unsurprising didn't find any.

All the variants are like this.

Timing attacks have been well known for a while, to the point that white hat guys I've mentioned Spectre to dismiss it as very old news. I too remember seeing stuff a couple of years ago about KVM instances using cache timing to communicate, and in one setup doing what Spectre does - one KVM instance reading the others memory. But that like Spectre it was proof of concept code. In reality getting the conditions required to pull it off in real life has proved impossible so far.

Xen FAQ

sampablokuper — Sat, 06 Jan 2018 20:52:30 +0000

From the linked post:

> "SP2 can be mitigated in two ways, both of which essentially prevent speculative execution of indirect branches. The first is to flush the branch prediction logic on entry into the hypervisor. This requires microcode updates, which Intel and AMD are in the process of preparing, as well as patches to the hypervisor which are also in process and should be available soon."

Given the Spectre, Meltdown, ME and PSP vulnerabilities, it is clear that Intel, AMD and ARM cannot be trusted to create secure systems, or even to adequately accept responsibility when their systems are shown to contain gross vulnerabilities.

As such, no-one should trust these forthcoming microcode updates not to make their host systems *less* secure.

Unless, that is, Intel and AMD break with recent traditions and make the microcode updates' contents open for public scrutiny and security auditing.

I'm not holding my breath.

A collection of Meltdown/Spectre postings

nix — Sat, 06 Jan 2018 15:43:11 +0000

5--10% overhead *if* the program is using PGO and LTO to minimize indirect calls?! So usually it's *worse*?!

This just gets worse and worse. I guess the only programs that need to use this are programs that are likely to be Spectre-impacted significantly (so it'll slow our web browsers down but probably not our desktops -- the desktops run JS these days but not hostile JS).

I hope distros don't rebuild *everything* with -z retpolineplt. An extra massive performance hit on top of the other massive performance hits... fairly soon at this rate the machine will be as slow as a 1989 PC (but with software that expects a far faster machine). I'm starting to see why CERT recommended to just throw your existing machines away.

A collection of Meltdown/Spectre postings

joib — Sat, 06 Jan 2018 14:16:19 +0000

> Christoph Hellwig already proposed some changes to the RISC-V privileged ISA: https://groups.google.com/a/groups.riscv.org/d/msg/isa-de...

Yes, I know, I posted that link myself a week ago: https://lwn.net/Articles/742301/ :) Not that I'm blaming you for missing it, considering the amount of posts left and right about this topic.

That being said, now that we have more information, I don't think that split page tables are strictly necessary. It seems Meltdown is due to a microarchitectural bug (or misfeature, if you will) in Intel CPU's, not an ISA level vulnerability. Split page tables could still be a good idea, in a belt-and-suspenders kind of way.

Spectre, OTOH, while not as serious as Meltdown right away, seems much more difficult to protect against without a significant performance penalty. And even so, I'm not sure there's much that can be specified at the ISA level.

A detection tool or even a monitoring plugin would be nice

excors — Sat, 06 Jan 2018 13:45:36 +0000

> That aside, if you can make a program execute arbitrary code, you've got much bigger problems that cache timing attacks.

That sounds like underplaying it. I think you don't have to run arbitrary code in the target process - Project Zero's "variant 1" only needs to run very tightly restricted code in the target process, in the form of eBPF (either JITted or not), but anything that can be manipulated to perform a similar sequence of operations (safely bounds-checked memory read then a dependent read) should be similarly vulnerable, which could include lots of APIs that don't involve code-like input at all. "variant 2" doesn't even need the target to willingly run attacker-influenced operations, because it tricks the CPU into running code at an arbitrary address in target process's context.

A detection tool or even a monitoring plugin would be nice

ras — Sat, 06 Jan 2018 12:07:49 +0000

> you need to do a lot more work if you intend to "weaponize it".

I don't think so. My problem is more in understanding of what is going on.

Confusingly, there are two closely related issues, which have named Spectre and Meltdown. Spectre boils down to this: if you can make a process execute a very specific sequence of instructions another process can "read" it's memory using a cache timing. The demo program tries to show it in action, but since forcing a program to execute a series of instructions it didn't intend to is a tad difficult it a demonstrates a process reading it's own memory without, err, actually reading it. It's the reading memory without asking the CPU to execute any instructions that actually read it that's generating the ooooh's and aaah's here, as obviously reading your own memory by asking the CPU to do it for you is rather common place. Nonetheless it does causes problems for programs like web browsers that assume a JavaScript code can only access memory the browser allows it to read. Now it's come to light random JavaScript can bypass those control's and access anything in the browsers memory it damned well pleases, I'm sure there is much hair pulling going on. That aside, if you can make a program execute arbitrary code, you've got much bigger problems that cache timing attacks. Which is good, because (a) every CPU that speculatively executes more than a couple of instructions is vulnerable to this and (b) there is no hardware fix.

The second issue is called Meltdown. This is the one that apparently caused the Intel CEO to sell as much of his Intel stock as the company allowed. It appears that rather than first checking if you are allowed to access memory then fetching it only if you are allowed to do so, Intel CPU's execute the two operations in parallel to speed things up. So the fetch always happens and the data ends up in cache - it is only the final step of passing the data to the program that fails. This means you could then probe what the data was by doing memory fetches, and using timing to detect whether it came from cache or not. Or you could if it weren't for that fact that a program doing an invalid memory access fails in a fairly spectacular way, a way that destroys the cache foot print you are look for. I thought you could bypass that by ensuring the instructions were executed speculatively, which means the Spectre demo program would have been able to read kernel memory - but apparently not. The paper says they use a more convoluted method involving side effects of transactional memory, however they also imply that just a speeds things up. I'm not sure what the exact trigger is, but whatever it is, only Intel has it. I find that remarkable given I was reading papers 20 years ago on the speed ups that could be obtained by doing memory fetches and permission checks in parallel. Fortunately there is a simple software fix: don't put the kernel in the user processes page table. Sadly this slows things down a little, because now the kernel has give itself access on every syscall.

Red Hat post is for RHEL customers only

roblucid — Sat, 06 Jan 2018 09:26:27 +0000

Speculative asking around was done, very important you follow up as intended or you endanger whole visible universe by a causality paradox!

Raspberry PI article is worth reading / fixing this in hardware ...

roc — Sat, 06 Jan 2018 07:22:55 +0000

This is more or less true for Meltdown, but not for Spectre unfortunately.

Raspberry PI article is worth reading / fixing this in hardware ...

JoeBuck — Sat, 06 Jan 2018 02:23:24 +0000

The Raspberry PI article is worth reading because it has the most intuitively clear explanation of how Meltdown works and how these attacks arise from speculative execution. It looks to me like this kind of attack could be easily prevented by a minor hardware design change.

The issue is that when an invalid read to memory is speculatively read, the resulting fault has to be deferred until the processor knows that we really branch in that direction, but nevertheless the value that is read is kept in the pipeline and can affect a subsequent read, which can be exploited to find out one bit at a time of an arbitrary location by preparing two memory locations, one of which is in cache and of which is not, and designing code that will read one or the other address based on some bit of the word we should have no access to.

But the processor should be able to read the state of protection of a memory word just as quickly as we read that memory word, and logic can do that operation in parallel In the article's example we conditionally read a kernel memory address, and the value of that read is stored in an internal register in the pipeline, even though we have no permission to read it. Instead, the read could be ANDed with a mask that would be all-ones if the data are accessible and all-zeros if not. Information would no longer be leaked: the true value of inaccessible memory could not influence anything else. Perhaps similar approaches could be used to deal with the branch-prediction issues as well. It should be possible to do this by spending a bit of area for the additional logic without slowing things down perceptibly; it might not be possible to fix it just with microcode though.

I guess this is what Linus was ranting about when it appeared Intel wasn't saying anything about real fixes. But the problem is, if Intel admits that this is a serious hardware design fault that they should compensate for with respins, it will cost them billions. Perhaps it's an opening for AMD though.

A collection of Meltdown/Spectre postings

cesarb — Fri, 05 Jan 2018 23:24:17 +0000

Another one from Red Hat: https://access.redhat.com/articles/3311301 ("Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables")

Open Tekekom Cloud patching

garloff — Fri, 05 Jan 2018 22:32:35 +0000

Here's the pointer to our assessment and progress on patching the Open Telekom Cloud (our public OpenStack cloud):
https://imagefactory.otc.t-systems.com/Blog-Review/SpecEx...

A collection of Meltdown/Spectre postings

freemars — Fri, 05 Jan 2018 21:48:29 +0000

Bruce Schneier at https://www.schneier.com/blog/archives/2018/01/spectre_an...

Red Hat post is for RHEL customers only

brooksmoses — Fri, 05 Jan 2018 21:02:13 +0000

Well, then, thank you! Much appreciated, and for your part in writing it as well.

A collection of Meltdown/Spectre postings

gioele — Fri, 05 Jan 2018 18:03:56 +0000

Christoph Hellwig already proposed some changes to the RISC-V privileged ISA: https://groups.google.com/a/groups.riscv.org/d/msg/isa-de...

Jacob Bachmeyer has posted a followup proposal: https://groups.google.com/a/groups.riscv.org/d/msg/isa-de...

The privileged ISA is going to change.

I hope the SiFive people and their Freedom U500 will not be affected too much.

A collection of Meltdown/Spectre postings

ufa — Fri, 05 Jan 2018 17:14:35 +0000

rpi isnt affected: https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vu...

A detection tool or even a monitoring plugin would be nice

ken — Fri, 05 Jan 2018 16:52:33 +0000

That code is just the prof of concept. It's not supposed to be able to read data from another process just test if the cpu it's run on has the underlying issue.

you need to do a lot more work if you intend to "weaponize it".

A detection tool or even a monitoring plugin would be nice

jcm — Fri, 05 Jan 2018 16:39:49 +0000

I was able to reproduce what is know "Meltdown" during the process of preparing mitigations. Even now, I won't share that publicly, but it is available to Red Hat's product security team and I have verified our RHEL kernels using various analysis. I was going to create a variant 2 ("Spectre") reproducer over the holidays, but that time got spent rewriting exception vectors for something else. Nonetheless, I've read all of the research from the TU Graz team over the past while, reproduced all of the standard side channel attacks, and am working within Red Hat to spin up various longer term architecture research efforts. I'm pretty keen that we find the next giant issue. It was interesting for me personally over the past little while because I've gotten to have a crash course in x86 architecture, including reading all (and I mean all) of the Intel manuals.

Red Hat post is for RHEL customers only

jcm — Fri, 05 Jan 2018 16:34:53 +0000

:) I'm looking forward to sleeping again. Hoping that happens next week!

A collection of Meltdown/Spectre postings

cesarb — Fri, 05 Jan 2018 14:46:22 +0000

The more I think about Spectre, the scarier it looks. I think it might be remotely exploitable, and this is acknowledged in passing at the end of the paper:

> While network-based attacks are conceivable, situations where an attacker can run code on the same CPU as the victim pose the primary risk.

Think of a network service which receives a packet, and does some conditional processing on it. An attacker could send several packets priming the branch predictor to go one way, then send a packet where the branch should go the other way but is speculated wrongly, and finally send a packet where the timing of the response is affected by some microarchitectural state which was changed by the speculated code. This should be really hard to pull off, but I see nothing preventing it, and attacks only get better.

A collection of Meltdown/Spectre postings

xjtuwjp — Fri, 05 Jan 2018 14:24:21 +0000

Debian has new intel-microcode package for CVE-2017-5715, not sure why intel hasn't publicly offer it.
https://tracker.debian.org/news/899110

A collection of Meltdown/Spectre postings

joib — Fri, 05 Jan 2018 12:59:13 +0000

It'll be interesting to see to which, if any, extent this causes a rethink of the RISC-V privileged ISA. "Thankfully" it's still in draft status, so I guess if they consider the issue severe enough, they can take a time-out and go back to the drawing board.

A collection of Meltdown/Spectre postings

ms — Fri, 05 Jan 2018 12:36:36 +0000

Thank you.

FWIW, mitigations from Firefox

Herve5 — Fri, 05 Jan 2018 10:45:02 +0000

present in the latest version 57.0.4 :
https://blog.mozilla.org/security/2018/01/03/mitigations-...

A collection of Meltdown/Spectre postings

pabs — Fri, 05 Jan 2018 09:41:18 +0000

https://riscv.org/2018/01/more-secure-world-risc-v-isa/

A collection of Meltdown/Spectre postings

arekm — Fri, 05 Jan 2018 07:44:38 +0000

"Intel has already issued updates for the majority of processor products"

Is microcode from 20171117 being that mentioned "update" ?

https://downloadcenter.intel.com/search?keyword=Linux*+Pr...

Red Hat post is for RHEL customers only

pbonzini — Fri, 05 Jan 2018 07:36:48 +0000

No, I went to bed and was going to do that today. :-) (Full disclosure!)

A collection of Meltdown/Spectre postings

Cyberax — Fri, 05 Jan 2018 05:02:07 +0000

Amazon is rebooting all the underlying hardware instances with patches against Meltdown: https://aws.amazon.com/security/security-bulletins/AWS-20...

A collection of Meltdown/Spectre postings

ms-tg — Fri, 05 Jan 2018 04:18:25 +0000

LWN quoted in CNN -- a first?
http://money.cnn.com/2018/01/03/technology/computer-chip-...

> Estimates posted on Linux message boards suggested computer performance
> could slow down between 5% and 30% once patched, however Intel said
> users will not see significant performance changes.

Red Hat post is for RHEL customers only

jcm — Fri, 05 Jan 2018 03:48:01 +0000

I spoke with the security team lead earlier and had it opened up. Thanks to Paolo for responding here also.

Red Hat post is public now

sasha — Fri, 05 Jan 2018 02:58:26 +0000

Thank you very much.

A detection tool or even a monitoring plugin would be nice

ras — Fri, 05 Jan 2018 02:19:34 +0000

> That code was copied from Appendix A of the Spectre paper,

Thanks. None of the obvious C errors are in the original paper.

It's looking a lot less terrifying now I've tried to get it to read the memory of a different process, and failed so far.