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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Apr 2015 13:35:06 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor
 attribute issue

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/