I'm really amazed by the simplicity of the meltdown gadget. After the initial blog post I played with a few variants, but always got the zeroed out register in the speculative branch. I guess what people (including me) were looking for here was some other side channel or instruction that did not have this mitigation in place (e.g. I had hoped a cmpxchg would leak whether the target memory address matches the register to compare with). The shl/retry loop makes a lot of sense if you instead assume that the mitigation was implemented improperly and can race subsequent uops. I really can't imagine why this data ever made it to the bypass network to be available to other uops.
Reading privileged memory with a side-channel
311–320 of 639 posts
Re: Reading privileged memory with a side-channel
#312From a recently posted patch set: Subject: Avoid speculative indirect calls in kernel Any speculative indirect calls in the kernel can be tricked to execute any kernel code, which may allow side channel attacks that can leak arbitrary kernel data. So we want to avoid speculative indirect calls in the kernel. There's a special code sequence called a retpoline that can do indirect calls without speculation. We use a ne…
Link?
Text and patch start here: https://lkml.org/lkml/2018/1/3/780
Also, see Linus' response here: https://lkml.org/lkml/2018/1/3/797
Re: Reading privileged memory with a side-channel
#313So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…
From the Spectre paper- We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones. So in ot…
Spectre and Meltdown are two different exploits. In this case, the paper is talking about Spectre and they did have a POC that worked on all three major processor families (except for deterministic execution engines in microcontrollers and low end CPUs from ARM as well as a few early Atoms from Intel). AMD is saying that Meltdown, which at first glance seems like the most serious one, doesn't effect their processors.
Re: Reading privileged memory with a side-channel
#314AMD put out an announcement:
Re: Reading privileged memory with a side-channel
#315Earlier quoted context omitted.
To make it a bit clearer how this works: the Variant 2 exploit poisons the branch target buffer to cause the processor's speculative execution in kernel space to jump to an entirely attacker-controlled destination when it hits a branch that matches the information the attacker has placed into the BTB. The actual retired instructions don't go this way of course - the processor detects the misprediction and goes back t…
But somehow you have to get that kernel address in the first place in order to alias it in the BTB. How do you get that without root?
They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor.
See the section "Reading host memory from a KVM guest / Locating the host kernel". It's terribly clever.
Re: Reading privileged memory with a side-channel
#316Earlier quoted context omitted.
Arm also claims it is working as intended: > Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog. I personally don't agree, but I guess they're trying to avoid needing to issue a recall for over ten years worth of CPUs?
Then surely you must also argue that all data-dependent, side-channel attacks, such as key recovery attacks against some cryptographic algorithm implementations, are the fault of the hardware. Unlike Intel, ARM and AMD are implicated only where the attacker can inject code or data (specifically data that is manipulated by pre-existing vulnerable code) into the target address space. The particular kernel exploits requ…
>The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code
Did they say that?
I don't see anything saying they were unable to, just that they didn't bother to because it would take effort.
>But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
Re: Reading privileged memory with a side-channel
#317Azure's response: https://azure.microsoft.com/en-us/blog/securing-azure-custom...
This part is interesting considering the performance concerns:
"The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some networking performance impact. This can be addressed by turning on Azure Accelerated Networking (Windows, Linux), which is a free capability available to all Azure customers."
Re: Reading privileged memory with a side-channel
#318Earlier quoted context omitted.
Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.
I can imagine some ways to armor the branch predictor, similar in principle to how languages like Perl have to include a random seed in their hash code (in some circumstances) to avoid being able to pre-compute values that will all hash to the same thing [1]. There should be some ways to relatively cheaply periodically inject such a randomization into the prediction system enough to prevent that aspect of the attack.…
I'm thinking you might be right.
It's going to be really hard to give up real world gains from branch prediction. Branch prediction can make a lot of real world (read "not the finest code in the world") run at reasonable speeds. Another common pattern to give up would be eliding (branch predicting away) nil reference checks.
> short of entirely preventing speculating code from being able to load things into the cache
Some new server processors allow us to partition cache (to prevent noisy neighbors) [1,2]. I don't have experience working with this technology but everything I read makes me believe this mechanism can works on a per process basis.
If that kind of complexity is already possible in CPU cache hierarchy I wonder if it's possible to implement per process cache encryption. New processors (EPYC) can already use different encryption keys for each VM, so it might be a matter of time till this is extended further.
Re: Reading privileged memory with a side-channel
#319Earlier quoted context omitted.
Yeah I was wondering this myself. Even if there's some fiddly hardware fix to make speculative execution secure, how much of its performance gains will we have to give up to get there?
Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.
[deleted]
Re: Reading privileged memory with a side-channel
#320Earlier quoted context omitted.
You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/
Just looking around, general available figures for public internet (as opposed to tor) suggest that anywhere between 0.1% to 1.0% of users have JS disabled. These numbers have also been consistently going down over time. That's a fairly small number to dictate how a system should be designed.
That depends on your target demographic. JS is more frequently disabled among tech-literate customers, so a cloud provider's home page would probably benefit from working without JS.