From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756602AbcECVFH (ORCPT ); Tue, 3 May 2016 17:05:07 -0400 Received: from mga02.intel.com ([134.134.136.20]:8882 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756437AbcECVFE (ORCPT ); Tue, 3 May 2016 17:05:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,574,1455004800"; d="scan'208";a="967984913" Subject: Re: [PATCH] [RFC] x86: work around MPX Erratum To: Ingo Molnar References: <20160502220341.9E8C34FC@viggo.jf.intel.com> <20160503064354.GA11112@gmail.com> Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Andy Lutomirski , Borislav Petkov , Thomas Gleixner , "H. Peter Anvin" , Linus Torvalds From: Dave Hansen Message-ID: <57291268.3060006@intel.com> Date: Tue, 3 May 2016 14:04:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160503064354.GA11112@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/02/2016 11:43 PM, Ingo Molnar wrote: >> > +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c) >> > +{ >> > + /* Only family 6 is affected */ >> > + if (c->x86 != 0x6) >> > + return 0; >> > + >> > + /* We know these Atom models are unaffected, for sure */ >> > + switch (c->x86_model) { >> > + case 0x5F: /* "Future Intel Atom ... Goldmont */ >> > + case 0x5C: /* "Future Intel Atom ... Goldmont */ >> > + return 0; >> > + } >> > + /* >> > + * We will get here on future unknown processors and all >> > + * Core/Xeons. They might be unaffected Atoms or >> > + * affected Core/Xeons. Be conservative and assume >> > + * processor is affected. >> > + * >> > + * Once the complete list of Core/Xeon models is known >> > + * it can be added here, and the Atom list removed. >> > + */ >> > + return 1; > So instead of trying to sort out the erratum, could we not just generally make MPX > dependent on SMEP and be done with it? MPX is a sophisticated security feature, > and it makes little sense to not do SMEP if you have it available. > > Anyone who is absolutely desperate to disable SMEP while enabling MPX is free to > step in and make his case. My concern was not necessarily with folks booting with 'nosmep', but with processors that have MPX present and SMEP fused off (or made unavailable by a hypervisor) and which are unaffected by this issue. People would have to be very careful to never create a processor which did not have SMEP but did have MPX, since MPX would effectively be unusable on such a processor.