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@arm.com
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@arm.com [florian: Adjust hyp-entry.S to account for the label added change to hyp/entry.S] Signed-off-by: Florian Fainelli f.fainelli@gmail.com
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@g... https://lore.kernel.org/linux-arm-kernel/20200720182937.14099-1-f.fainelli@g... https://lore.kernel.org/linux-arm-kernel/20200709195034.15185-1-f.fainelli@g...
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?