| Meltdown and Spectre Vulnerabilities | Christopher Celio | 07/01/18 23:07 | Hey everyone, Since the Meltdown and Spectre vulnerabilities have been a very popular topic for the last few days, and I've seen a lot of misinformation going around regarding them, I thought I'd make a post to clarify a few things from BOOM's point of view. The background information can be found at: First, I am still digesting all of this information, and it may take a while for us as a community to fully process the consequences of these attacks and what the best mitigation techniques are. With that said, here are my (preliminary) thoughts on this topic. BOOM is not susceptible to Meltdown. Meltdown appears to rely on bypassing load data that failed a permissions check. As BOOM checks the TLB as part of the dcache access pipeline, the permission violation is detected immediately and load data bypass and write-back is suppressed. There is no additional speculative cache access using the privileged data as its address. Spectre is more complex, but it appears that both disclosed variants ("bounds check bypass" and "branch target injection") rely on two components to work: 1) a way for an attacker thread to force a victim thread to speculatively execute an existing "gadget", and 2) a covert channel to gain information from the gadget. In other words, Spectre relies on a malicious thread injecting information into a shared BTB/BPD structure. BOOM is currently susceptible to this, but a number of relatively simple, low-impact changes to the BTB/BPD structure (such as flushing or tagging) can guard against Spectre. However, there is one form of Spectre that is confounding --- when the attacker thread and the victim thread are one and the same. In this scenario, there is no way to flush the BTB/BPD between the attacker setting up the misdirection and the victim speculatively executing it. I contend in this scenario that we have a software bug --- the software is attempting to enforce its own domain protections and not leveraging the existing protection mechanisms provided by the hardware (think of a sandboxed JIT that is running untrusted code with supervisor permissions). In this scenario, any act of speculative (not just speculative cache allocations) leaks information. So far, I have seen a few ideas that have been proposed: * allow SW to flush the BTB/BPD --- I'm not sure this will work as even a flushed BPD makes predictions, and a "not-taken" prediction is all that is required to force the leak. * allow SW to insert speculation fences --- I'm concerned this is only a temporary patch, as it only protects known gadgets from attacks. * force SW to move protected information to a protected hw domain --- I'm not sure how tenable this is, particularly in the short-term. Long-term, I suspect this might be the likely end-game. The nice thing about open-source is that somebody can perform attacks on an understood system, somebody else can make the changes to mitigate the attack, and a third person can verify the mitigation. =) -Chris |
| Re: Meltdown and Spectre Vulnerabilities | Tapabrata Ghosh | 07/01/18 23:22 | >> "* allow SW to insert speculation fences --- I'm concerned this is only a temporary patch, as it only protects known gadgets from attacks." This is the proposed solution in the Spectre paper IIRC, with the solution being to JIT in lfence or mfence instructions, at a potentially severe performance penalty. In the short term it seems like the painful Reptoline is the only mitigation. BTW, I have a solution for the case where the attacker thread and victim thread are the same, and I don't think such a situation would necessarily qualify as a software bug, that code could be as simple as a password check. |
| Re: Meltdown and Spectre Vulnerabilities | sor...@gmail.com | 07/01/18 23:35 | On Sun, Jan 7, 2018 at 11:07 PM, Christopher Celio wrote:This is accurate for variant 2 but not for variant 1. Variant 1 attacks can use *any* misprediction, so it is not necessary to inject information into the BPD; it is sufficient to wait for a natural misprediction. Variant 1 attacks can either attack a target in the same thread/privilege domain or a target in a different thread/privilege domain. Since no injection is required by the attack, no BPD-level countermeasure is possible. Per the above, I do not think this is accurate. The only watertight solution I see is to disable execution of loads, stores, divides, and integer multiplies (if no IMul) behind an unresolved branch. It is fairly straightforward to argue that the timing-channel leakage with that modification is the same as the timing-channel leakage of a non-pipelined processor. Memory dependence speculation (both positive and negative) raises substantially identical problems and would need to be disabled. Rich Felker proposed "Loads whose address depend on another speculative load should never be executed speculatively."; this is superficially attractive, but NOT a complete fix, as when using tagged pointers (possibly other cases) a misspeculation can cause the *first* load after a branch to use a value as an address that should not be leaked. With speculative loads hindered in this way it is not necessary to clear BTBs on privilege change, although it may be attractive as a defense in depth. All of these concerns are immaterial in a batch-processing environment where a single confidentiality domain occupies the entire machine (or a robust partition of the machine) for a sufficiently long computation to prevent adversarial timing. So it may make sense to have a "batch mode" which permits more speculation but clears caches on entry and exit … Agreed. -s |
| Re: Meltdown and Spectre Vulnerabilities | Christopher Celio | 08/01/18 01:27 | Thanks S, So to summarize our IRC discussion, a malicious user thread can use a syscall to invoke the gadget directly with the desired inputs in an attack against the kernel (or IPC to attack user-level threads). Flushing the BTB/BPD does not defend against this despite the change in priv mode. An example is a malicious user calling into the OS via a Close() syscall (somewhat psuedo-code): int close(int fd) { if (fd < process.file_num) { process.files[fd].vtable.close(process.files[fd]); process.files[fd] = 0; return 0; } else { return -EBADF; } } The first thing the Close() does after fetching the file object is to load a vtable from it. That vtable fetch will leak bits from the out-of-bounds read. Apparently the current fix is to use static analysis tools to find untrusted inputs used to drive data dependent loads and insert speculation fences: http://lkml.iu.edu/hypermail/linux/kernel/1801.0/04201.html RISC-V does not have any dependable mechanism that I'm aware of to insert a speculation barrier. Blocking speculative cache allocations is likely only a bandaid, as other mechanisms can leak speculative information. -Chris |