linux-kernel - Re: [RFC PATCH] x86/cpu: Fix MSR value truncation 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] [day] [month] [year] [list]

Date:	Wed, 11 Nov 2015 13:07:34 -0500
From:	Brian Gerst <brgerst@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH] x86/cpu: Fix MSR value truncation issue

On Wed, Nov 11, 2015 at 11:05 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Wed, Nov 11, 2015 at 07:50:04AM -0800, Andy Lutomirski wrote:
>
>> Not terribly surprising :)  Someone (I forget who) told me that 32-bit
>> SYSCALL (native 32-bit, not compat) was so full of errata that it was
>> unusable.  Even without errata, I don't really see how it would work
>> well

I had tried to implement it when the K6 came out, but the major
problem was that implementation set an internal flag that forced
return to userspace with SYSRET.  IRET would fault, which made task
switching a big problem.

Specifically, the SYSCALL description for the K6 has this text:
"The CS and SS registers should not be modified by the operating
system between the
execution of the SYSCALL instruction and its corresponding SYSRET instruction."

It's likely that behavior has been fixed on modern 64-bit AMD cpus
running in legacy mode, but I haven't tested it.  It's not really
worth pursuing.

> No, showstopper appears much earlier: it is only supported on AMD. Which
> would mean, yet another vendor special-handling. And I don't think it's
> worth it.
>
> Yeah, yeah, it might still be faster than SYSENTER, but 32-bit?! Srsly?!
> I'm surprised that thing still builds even. :-)
>
>> -- there's no MSR_SYSCALL_MASK,
>
> Of course there is:
>
> MSRC000_0084 SYSCALL Flag Mask (SYSCALL_FLAG_MASK):
>
> 31:0 - Mask: SYSCALL flag mask. Read-write. Reset: 0000_0000h. This register holds the EFLAGS
> mask used by the SYSCALL instruction. 1=Clear the corresponding EFLAGS bit when executing the
> SYSCALL instruction.
>
> Intel has that too, except again, no SYSCALL in legacy mode on Intel.

SYSCALL_FLAG_MASK was added with the 64-bit processors.  It's not used
in legacy mode according to the AMD docs.

--
Brian Gerst
--
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/