Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[Borislav Petkov]

On Mon, Apr 27, 2015 at 10:53:05AM +0200, Borislav Petkov wrote:
> 	ALTERNATIVE "",
> 		    "shl     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
> 		     sar     $(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx \
> 		     cmpq    %rcx, %r11 \
> 		     jne     opportunistic_sysret_failed"
> 		     X86_BUG_SYSRET_CANONICAL_RCX

Right, so I can do this:

        /*
         * Change top 16 bits to be the sign-extension of 47th bit, if this
         * changed %rcx, it was not canonical.
         */
        ALTERNATIVE "", \
                "shl    $(64 - (47+1)), %rcx; \
                 sar    $(64 - (47+1)), %rcx; \
                 cmpq   %rcx, %r11; \
                 jne    opportunistic_sysret_failed", X86_BUG_SYSRET_CANON_RCX

If I use the __VIRTUAL_MASK_SHIFT macro *in* the ALTERNATIVE macro, I get some
really cryptic gas error:

arch/x86/kernel/entry_64.S: Assembler messages:
arch/x86/kernel/entry_64.S:441: Error: can't resolve `L0' {*ABS* section} - `L0' {*UND* section}
scripts/Makefile.build:294: recipe for target 'arch/x86/kernel/entry_64.o' failed
make[1]: *** [arch/x86/kernel/entry_64.o] Error 1
Makefile:1536: recipe for target 'arch/x86/kernel/entry_64.o' failed
make: *** [arch/x86/kernel/entry_64.o] Error 2

but I guess we can simply use the naked "47" because a couple of lines
above, we already have the sanity-check:

        .ifne __VIRTUAL_MASK_SHIFT - 47
        .error "virtual address width changed -- SYSRET checks need update"
        .endif

so we should be guarded just fine.

Anyway, if we do it this way, we get 17 NOPs added at build time which is the
length of the 4 instructions:

ffffffff819ef40c:       48 c1 e1 10             shl    $0x10,%rcx
ffffffff819ef410:       48 c1 f9 10             sar    $0x10,%rcx
ffffffff819ef414:       49 39 cb                cmp    %rcx,%r11
ffffffff819ef417:       0f 85 ff 9c bc ff       jne    ffffffff815b911c <opportunistic_sysret_failed>

and the 17 NOPs should be optimized at boot time on AMD.

I was initially afraid that the JMP in the 4th line might be wrong but
apparently since we're using a global label, gas/gcc does generate the
offset properly (0xffffffff815b911c):

ffffffff815b911c <opportunistic_sysret_failed>:
ffffffff815b911c:       ff 15 fe a4 26 00       callq  *0x26a4fe(%rip)        # ffffffff81823620 <pv_cpu_ops+0x120>
ffffffff815b9122:       e9 01 09 00 00          jmpq   ffffffff815b9a28 <restore_c_regs_and_iret>
ffffffff815b9127:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
ffffffff815b912e:       00 00

So, on to do some tracing.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/