Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751762AbbKKSHg (ORCPT ); Wed, 11 Nov 2015 13:07:36 -0500 Received: from mail-oi0-f50.google.com ([209.85.218.50]:33915 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbbKKSHf (ORCPT ); Wed, 11 Nov 2015 13:07:35 -0500 MIME-Version: 1.0 In-Reply-To: <20151111160515.GH22512@pd.tnic> References: <1446226105-13384-1-git-send-email-bp@alien8.de> <20151111123158.GF22512@pd.tnic> <20151111160515.GH22512@pd.tnic> Date: Wed, 11 Nov 2015 13:07:34 -0500 Message-ID: Subject: Re: [RFC PATCH] x86/cpu: Fix MSR value truncation issue From: Brian Gerst To: Borislav Petkov Cc: Andy Lutomirski , LKML , Andy Lutomirski , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Peter Zijlstra , Thomas Gleixner Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2042 Lines: 51 On Wed, Nov 11, 2015 at 11:05 AM, Borislav Petkov 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/