On 01/11/2018 03:04 AM, Alan Modra wrote: > On Wed, Jan 10, 2018 at 05:13:36PM -0700, Jeff Law wrote: >> On 01/08/2018 07:23 AM, Alan Modra wrote: >>> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote: >>>> On 01/07/2018 03:58 PM, H.J. Lu wrote: >>>>> This set of patches for GCC 8 mitigates variant #2 of the speculative >>>>> execution >>>>> vulnerabilities on x86 processors identified by CVE-2017-5715, aka >>>>> Spectre. >>> [snip] >>>> My fundamental problem with this patchkit is that it is 100% x86/x86_64 >>>> specific. >>> >>> It's possible that x86 needs spectre variant 2 mitigation that isn't >>> necessary on other modern processors like ARM and PowerPC, so let's >>> not rush into general solutions designed around x86.. >> >From what I know about variant 2 mitigation it's going to be needed on a >> variety of chip families, not just the Intel architecture. > > Yes. I was thinking that it might be possible ignore variant 2 > attacks if there were no gadgets available anywhere in the victim > address space, which is true enough but difficult to achieve. That > led me to think that indirect branches didn't matter, until someone > pointed out that the indirect branch attack could be chained. If you > have the first part of a gadget, the read of interesting memory, > followed by an indirect branch, that indirect branch can be spoofed > into code that uses the interesting value in a way that affects cache > state. Note that even though variant 2 potentially applies to many architectures and I believe we could do a fairly generic retpoline implementation that would provide a high level of protection across many targets that may not be the best choice.
As I mentioned in a message last night, some of the processor vendors seem to want to go a different direction. I'll summarize those as "add this magic instruction to the indirect call/jump sequence". They're typically just a single insn and fairly trivial to implement. They may require using a different branch instruction as well. But again, trivial to implement. Given that divergence I think we really want to look closely at HJ's code for x86/x86_64 and let the other processor vendors work towards their own mitigations -- ultimately with everyone doing their own thing in their target files :( Jeff
