The "fix" is NOT "Don't allow speculative execution", rather the "fix" is to code the O/S such that this exploit is not possible.
Intel fails out to spectre meltdown full#
IOW the compiler should generate code that takes full advantage of any speculative execution capability of the processors. There should be no changes to the compilers for this as the attacker would simply write the code in assembler. This should cause the speculative code to fetch (as index) data from a faulting page or the innocuous data for use as index.Īndrew> My concern arises from the some of the code emissions going into GCC and LLVM IOW the exploit could be thwarted if the page table entry (for the protected data) of the user process (when at user level) is invalidated or points to an innocuous page and that on transition to ring 0/1 (at privileged mode) the page table entry is properly set, then on exit is reset. Isn't the problem that the "protected" data is still mapped to the attacking process (e.g. John> but fails to prevent speculative execution from using protected data to make reliably detectable changes in the cache state. The Spectre paper concludes with a listing of other techniques that could be applied in conjunction with speculative execution to create data leaks, but without specific implementations and demonstrations, it is unclear whether these are serious potential threats or just random speculation. Clearing the branch prediction history on context switches (or saving and restoring it as an explicit part of the process context) would eliminate the primary tool used by Spectre. Using a shared branch predictor might have been necessary in the first processors that supported HyperThreading, but it is difficult to imagine that there is any value in keeping it shared in the era of multi-billion transistor processors. It is probably possible, but would likely have significantly more noise and significantly lower bandwidth than the attack based on using the alternate HyperThread on a core with a shared branch predictor. Although the authors of the Spectre paper say that they have shown that this can be used to cause branch mistraining on Skylake processors, they don't show that they were able to generate a working exploit in this mode. If HyperThreading is disabled, the attacking thread has to attempt to bias the branch predictor of the target process by running on the same physical core in alternating time slices. The demonstrations referred to in the Spectre paper placed the attacking thread in the alternate HyperThread of the physical core where the target process was running. Spectre is a much lower-bandwidth covert channel (10kB/s vs 500kB/s for Meltdown), but it is not as easily blocked as Meltdown. (I.e., the kernel interrupt handler could monitor for page faults caused by a user process attempting to load kernel pages and take action if this occurs too frequently.) Ironically, Intel's TSX extensions provide a large increase in the throughput of the Meltdown attack, as well as eliminating the exceptions that could be monitored by the OS. AMD was right to block this case before execution (since there is no case in which the memory access would be allowed to complete, allowing it to execute speculatively provides no benefits). This provides a high-bandwidth covert channel for reading protected data. The Intel hardware does maintain zero-order protection across protection domains, but fails to prevent speculative execution from using protected data to make reliably detectable changes in the cache state. Meltdown could be considered a design flaw in the OS, but it was really a team effort between the hardware and software.
0 kommentar(er)
