On 8/21/20 9:03 AM, Will Deacon wrote: > On Fri, Aug 07, 2020 at 03:14:29PM +0200, Greg KH wrote: >> On Thu, Aug 06, 2020 at 01:00:54PM -0700, Florian Fainelli wrote: >>> >>> >>> On 7/20/2020 11:26 AM, Florian Fainelli wrote: >>>> On 7/20/20 6:04 AM, Greg KH wrote: >>>>> On Thu, Jul 09, 2020 at 12:50:23PM -0700, Florian Fainelli wrote: >>>>>> From: Will Deacon <will.deacon@xxxxxxx> >>>>>> >>>>>> commit 679db70801da9fda91d26caf13bf5b5ccc74e8e8 upstream >>>>>> >>>>>> Some CPUs can speculate past an ERET instruction and potentially perform >>>>>> speculative accesses to memory before processing the exception return. >>>>>> Since the register state is often controlled by a lower privilege level >>>>>> at the point of an ERET, this could potentially be used as part of a >>>>>> side-channel attack. >>>>>> >>>>>> This patch emits an SB sequence after each ERET so that speculation is >>>>>> held up on exception return. >>>>>> >>>>>> Signed-off-by: Will Deacon <will.deacon@xxxxxxx> >>>>>> [florian: Adjust hyp-entry.S to account for the label >>>>>> added change to hyp/entry.S] >>>>>> Signed-off-by: Florian Fainelli <f.fainelli@xxxxxxxxx> >>>>>> --- >>>>>> Changes in v2: >>>>>> >>>>>> - added missing hunk in hyp/entry.S per Will's feedback >>>>> >>>>> What about 4.19.y and 4.14.y trees? I can't take something for 4.9.y >>>>> and then have a regression if someone moves to a newer release, right? >>>> >>>> Sure, send you candidates for 4.14 and 4.19. >>> >>> Greg, did you have a chance to queue those changes for 4.9, 4.14 and 4.19? >>> >>> https://lore.kernel.org/linux-arm-kernel/20200720182538.13304-1-f.fainelli@xxxxxxxxx/ >>> https://lore.kernel.org/linux-arm-kernel/20200720182937.14099-1-f.fainelli@xxxxxxxxx/ >>> https://lore.kernel.org/linux-arm-kernel/20200709195034.15185-1-f.fainelli@xxxxxxxxx/ >> >> Nope, I was waiting for Will's "ack" for these. > > This patch doesn't even build for me (the 'sb' macro is not defined in 4.9), > and I really wonder why we bother backporting it at all. Nobody's ever shown > it to be a problem in practice, and it's clear that this is just being > submitted to tick a box rather than anything else (otherwise it would build, > right?). Doh, I completely missed submitting the patch this depended on that's why I did not notice the build failure locally, sorry about that, what a shame. Would not be the same "tick a box" argument be used against your original submission then? Sure, I have not been able to demonstrate in real life this was a problem, however the same can be said about a lot security related fixes. What if it becomes exploitable in the future, would not it be nice to have it in a 6 year LTS kernel? > > So I'm not going to Ack any of them. As with a lot of this side-channel > stuff the cure is far worse than the disease. Assuming that my v3 does build correctly, which it will, would you be keen on changing your position? -- Florian
