On Mon, Sep 12, 2022 at 02:56:16PM -0700, Pawan Gupta wrote:
On Sun, Sep 11, 2022 at 07:47:25AM +0200, Greg KH wrote:
On Thu, Sep 08, 2022 at 02:44:33PM +0200, Ben Hutchings wrote:
On Wed, 2022-09-07 at 23:09 -0700, Pawan Gupta wrote:
On Wed, Sep 07, 2022 at 02:23:58AM +0200, Ben Hutchings wrote:
> - The added mitigation, for PBRSB, requires removing any RET > instructions executed between VM exit and the RSB filling. In these > older branches that hasn't been done, so the mitigation doesn't work.
I checked 4.19 and 5.4, I don't see any RET between VM-exit and RSB filling. Could you please point me to any specific instance you are seeing?
Yes, you're right. The backported versions avoid this problem. They are quite different from the upstream commit - and I would have appreciated some explanation of this in their commit messages.
Ahh right, I will keep in mind next time.
So, let's try again to move forward. I've attached a backport for 4.19 and 5.4 (only tested with the latter so far).
I am not understanding why lfence in single-entry-fill sequence is okay on 32-bit kernels?
#define __FILL_ONE_RETURN \ __FILL_RETURN_SLOT \ add $(BITS_PER_LONG/8), %_ASM_SP; \ lfence;
This isn't exactly about whether the kernel is 32-bit vs 64-bit, it's about whether the code may run on a processor that lacks support for LFENCE (part of SSE2).
- SSE2 is architectural on x86_64, so 64-bit kernels can use LFENCE
unconditionally.
- PBRSB doesn't affect any of those old processors, so its mitigation
can use LFENCE unconditionally. (Those procesors don't support VMX either.)
Ok, it seems that I need to take Ben's patch to resolve this. Pawan, if you object, please let us know.
I don't see any issue taking Ben's patch to resolve this.
Backport for 5.4 didn't apply cleanly on 4.19 and needed a minor change.
Attaching the patch for 4.19. It built fine with CONFIG_64BIT=n.
We already had a 4.19 patch, but I'll add your signed-off-by to it :)
thanks,
greg k-h