Re: [PATCH] x86/bugs: Use fixed addressing for VERW operand

From: Pawan Gupta
Date: Thu Feb 29 2024 - 04:15:09 EST

On Wed, Feb 28, 2024 at 05:39:27PM -0800, Pawan Gupta wrote:
> On Tue, Feb 27, 2024 at 10:43:53AM +0100, Jiri Slaby wrote:
> > On 27. 02. 24, 9:47, Nikolay Borisov wrote:
> > >
> > >
> > > On 27.02.24 г. 1:52 ч., Pawan Gupta wrote:
> > > > Macro used for MDS mitigation executes VERW with relative addressing for
> > > > the operand. This is unnecessary and creates a problem for backports on
> > > > older kernels that don't support relocations in alternatives. Relocation
> > > > support was added by commit 270a69c4485d ("x86/alternative: Support
> > > > relocations in alternatives"). Also asm for fixed addressing is much
> > > > more cleaner than relative RIP addressing.
> > > >
> > > > Simplify the asm by using fixed addressing for VERW operand.
> > > >
> > > > Fixes: baf8361e5455 ("x86/bugs: Add asm helpers for executing VERW")
> > > > Reported-by: Nikolay Borisov <nik.borisov@xxxxxxxx>
> > > > Closes: https://lore.kernel.org/lkml/20558f89-299b-472e-9a96-171403a83bd6@xxxxxxxx/
> > > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>
> > > > ---
> > > >   arch/x86/include/asm/nospec-branch.h | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/include/asm/nospec-branch.h
> > > > b/arch/x86/include/asm/nospec-branch.h
> > > > index 2aa52cab1e46..ab19c7f1167b 100644
> > > > --- a/arch/x86/include/asm/nospec-branch.h
> > > > +++ b/arch/x86/include/asm/nospec-branch.h
> > > > @@ -323,7 +323,7 @@
> > > >    * Note: Only the memory operand variant of VERW clears the CPU
> > > > buffers.
> > > >    */
> > > >   .macro CLEAR_CPU_BUFFERS
> > > > -    ALTERNATIVE "", __stringify(verw _ASM_RIP(mds_verw_sel)),
> > > > X86_FEATURE_CLEAR_CPU_BUF
> > > > +    ALTERNATIVE "", __stringify(verw mds_verw_sel),
> > > > X86_FEATURE_CLEAR_CPU_BUF
> > >
> > > Actually thinking about it more and discussing with Jiri (cc'ed), will
> > > this work with KASLR enabled?
> >
> > I might of course be wrong. We appear to rely on the asm+linker here.
>
> You were right, with KASLR enabled, instructions with fixed addressing
> in alternatives don't get relocated. I guess we will have to keep
> rip-relative as is. Thanks for catching that.

Looks like this is not settled yet, it was naive of me to trust gdb on
/proc/kcore earlier with KASLR enabled.

With the below debug patch it appears the relocation with fixed
addresses is working as expected with KASLR enabled.

diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 6a1fe302c1fd..ae4168db453d 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -323,7 +323,7 @@
* Note: Only the memory operand variant of VERW clears the CPU buffers.
*/
.macro CLEAR_CPU_BUFFERS
- ALTERNATIVE "", __stringify(verw mds_verw_sel), X86_FEATURE_CLEAR_CPU_BUF
+ ALTERNATIVE "", __stringify(verw mds_verw_sel; ud2), X86_FEATURE_CLEAR_CPU_BUF
.endm

#else /* __ASSEMBLY__ */
---

With the patch adding #UD after verw I get below panic:

[ 1.402347] traps: PANIC: double fault, error_code: 0x0
[ 1.402350] double fault: 0000 [#1] PREEMPT SMP PTI
[ 1.402353] CPU: 0 PID: 1 Comm: init Not tainted 6.7.6-00007-ga040ab9fe827-dirty #27
[ 1.402355] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 1.402356] RIP: 0010:entry_SYSRETQ_unsafe_stack+0xb/0x10
[ 1.402365] Code: c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 00 00 48 81 cf 00 10 00 00 0f 22 df 58 5f 5c 0f 01 f8 0f 00 2c 25 00 00 60 ab <0f> 0b 48 0f 07 cc 0f 1f 44 00 00 56 48 8b 74 24 08 48 89 7c 24 08
[ 1.402366] RSP: 0018:00007ffe253461f8 EFLAGS: 000100c6
[ 1.402369] RAX: 000055e5c94f7000 RBX: 00007f3d8d9b4e80 RCX: 00007f3d8d9b8f9b
[ 1.402370] RDX: 0000000000000000 RSI: 00007ffe253461ec RDI: 0000000000000000
[ 1.402371] RBP: 00007ffe25346290 R08: 0000000000000000 R09: 0000000000000022
[ 1.402372] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3d8d993000
[ 1.402373] R13: 0000002300000007 R14: 0000000000000007 R15: 00007ffe253462a0
[ 1.402378] FS: 0000000000000000(0000) GS:ffff906d3bc00000(0000) knlGS:ffff906d3bc00000
[ 1.402380] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.402381] CR2: 00007ffe253461e8 CR3: 00000001002a8003 CR4: 00000000007706f0
[ 1.402382] PKRU: 55555554
[ 1.402383] Call Trace:
[ 1.402384] <#DF>
[ 1.402386] ? die+0x37/0x90
[ 1.402390] ? exc_double_fault+0xcf/0x180
[ 1.402394] ? asm_exc_double_fault+0x23/0x30
[ 1.402397] ? entry_SYSRETQ_unsafe_stack+0xb/0x10
[ 1.402400] </#DF>
[ 1.402401] Modules linked in:
[ 1.402403] Dumping ftrace buffer:
[ 1.402406] (ftrace buffer empty)
[ 1.402407] ---[ end trace 0000000000000000 ]---
[ 1.402408] RIP: 0010:entry_SYSRETQ_unsafe_stack+0xb/0x10
[ 1.402411] Code: c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 00 00 48 81 cf 00 10 00 00 0f 22 df 58 5f 5c 0f 01 f8 0f 00
2c 25 00 00 60 ab <0f> 0b 48 0f 07 cc 0f 1f 44 00 00 56 48 8b 74 24 08 48 89 7c 24 08
[ 1.402412] RSP: 0018:00007ffe253461f8 EFLAGS: 000100c6
[ 1.402413] RAX: 000055e5c94f7000 RBX: 00007f3d8d9b4e80 RCX: 00007f3d8d9b8f9b
[ 1.402414] RDX: 0000000000000000 RSI: 00007ffe253461ec RDI: 0000000000000000
[ 1.402415] RBP: 00007ffe25346290 R08: 0000000000000000 R09: 0000000000000022
[ 1.402416] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3d8d993000
[ 1.402417] R13: 0000002300000007 R14: 0000000000000007 R15: 00007ffe253462a0
[ 1.402419] FS: 0000000000000000(0000) GS:ffff906d3bc00000(0000) knlGS:ffff906d3bc00000
[ 1.402420] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.402421] CR2: 00007ffe253461e8 CR3: 00000001002a8003 CR4: 00000000007706f0
[ 1.402422] PKRU: 55555554
[ 1.402423] Kernel panic - not syncing: Fatal exception in interrupt
[ 1.402551] Dumping ftrace buffer:
[ 1.402552] (ftrace buffer empty)
[ 1.402552] Kernel Offset: 0x29400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
^
Note the KASLR offset
~~~~~~~~~~~~~~~~~~~~~

Disassembling the code stream in the trace ... :

eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 00 00 48 81 cf 00 10 00 00 0f 22 df 58 5f 5c 0f 01 f8 0f 00 2c 25 00 00 60 ab 0f 0b 48 0f 07 cc 0f 1f 44 00 00 56 48 8b 74 24 08 48 89 7c 24 08

.. gives:

jmp 0xa
mov rdi, rax
bts rdi, 0x3f
or rdi, 0x800
or rdi, 0x1000
mov cr3, rdi
pop rax
pop rdi
pop rsp
swapgs
verw word ptr [0xffffffffab600000] <----- mds_verw_sel
ud2
sysretq
int3
nop dword ptr [rax + rax]
push rsi
mov rsi, qword ptr [rsp + 8]
mov qword ptr [rsp + 8], rdi

$ objdump -S --disassemble=mds_verw_sel vmlinux

ffffffff82200000 <mds_verw_sel>:
ffffffff82200000: 18 00 sbb %al,(%rax)

Adding KASLR offset to mds_verw_sel:

0xffffffff82200000 + 0x29400000 = 0xffffffffab600000

which is the address of mds_verw_sel after KASLR that we saw in the code
stream disassembly. To me it looks like fixed addresses for VERW is
working as intended. Please let me know if I am missing something. It
will be great if someone can independently verify this.

Even with fixed addressing working with KASLR it may still be a good
idea to stick with RIP relative addresses as they are less likely to
be broken with relocation.

And sorry for the noise.