Received: by 10.223.185.116 with SMTP id b49csp846500wrg; Fri, 16 Feb 2018 08:07:07 -0800 (PST) X-Google-Smtp-Source: AH8x227J7lZlIIGOfU9+nV2BxYfN8hLfExsotemi+vwCGPU0akaBN9fN1YXuOfOM/H3f1E3JGTkY X-Received: by 10.99.60.72 with SMTP id i8mr5453607pgn.399.1518797226977; Fri, 16 Feb 2018 08:07:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518797226; cv=none; d=google.com; s=arc-20160816; b=ybxkHlhFE7Wc+vdELnX0eXwGmesdUU683Hoc5KHqgdfwXRhLfX19tekEMsY2+12Ure zQh/bWF2MJXRykHQDXNOR9/BvJC/NWdTjSgEnuKshW7sBjesN+MGk+/ex8rmehC2QHbK wIOsW/J8NkxQy4O9CjkinsY2ustL8mN+hzpbDD2/PnO8yhdi093Ygbg+23MRLGMVgu9e KMEQLSwMFwya7lLVn+x9ZfrvU0GabkVuRsGlId/jvKo7NQqOO7dNky3b4aPLDx5T9CZN AL2sYAt/wE+c0/xdcWyVJoFzUAoJphszXGnrY06Ej8X8WjE8FA1Ap4Ktp1XzN0ysr+7v JKuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=5C9zuxxKf8C+EaeacRWp/mWDNz6eXdIhOux2XerzGYs=; b=dW0uawdIvKI7CxsQv5s/SRtzMm54WsftrEg+Hc+q5zYnjkJGfRzCEs6gqHkWTYkpMl KK1i+3qs0wj1MsVUR5+G1QZ0ChteZthnZ6Ur3miujomD3THwg1fRk6l43tVCHWno8+6h ++2nCa9JUqBCZXqigT8P/6zsWARoZ2jF+d410mTg1iQ/Ua04TWK4WHn6uWpFVyDxOOaJ dLYAsD3ce3jA1Ko3DlKirR9I2m+bR6MtT5MpEQl95JH9MIIESuEugq6Iw9qkUY/5elU/ gasxr+YUfo8sfVky9DYifv1LA00EBmU2lrEuFkOqK+3qaaTId0BGnKIBscFsCIZKWbKE 4j0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si3204666plx.791.2018.02.16.08.06.52; Fri, 16 Feb 2018 08:07:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756792AbeBPAmx (ORCPT + 99 others); Thu, 15 Feb 2018 19:42:53 -0500 Received: from mga12.intel.com ([192.55.52.136]:6524 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752984AbeBPAmw (ORCPT ); Thu, 15 Feb 2018 19:42:52 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 16:42:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,519,1511856000"; d="scan'208";a="18132304" Received: from schadtlo-mobl1.amr.corp.intel.com (HELO [10.254.79.79]) ([10.254.79.79]) by fmsmga007.fm.intel.com with ESMTP; 15 Feb 2018 16:42:51 -0800 Subject: Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode To: Nadav Amit References: <20180215163602.61162-1-namit@vmware.com> <27a0082c-fadb-792a-740e-70932d51f1b5@linux.intel.com> <91CEEFA7-86C8-4731-BC7E-6AF5CC3A1BA4@gmail.com> Cc: Ingo Molnar , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Willy Tarreau , x86@kernel.org, linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: <9a825978-fe69-1c10-0da0-0c67dbb9b232@linux.intel.com> Date: Thu, 15 Feb 2018 16:42:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <91CEEFA7-86C8-4731-BC7E-6AF5CC3A1BA4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/15/2018 04:25 PM, Nadav Amit wrote: > Dave Hansen wrote: > >> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>> I removed the PTI disabling while SMEP is unsupported, although I >>> must admit I did not fully understand why it is required. >> >> Do you mean you don't fully understand how PTI gives SMEP-like behavior >> on non-SMEP hardware? > > No. I understand how it provide SMEP-like behavior, and I understand the value > of SMEP by itself. > > However, I do not understand why SMEP-like protection is required to protect > processes that run in compatibility-mode from Meltdown/Spectre attacks. As > far as I understand, the process should not be able to manipulate the kernel > to execute code in the low 4GB. There are two problems: one is that regardless of Meltdown/Spectre, SMEP is valuable. It's valuable to everything, compatibility-mode or not. The second problem is the RSB. It has a full-width virtual address and, unlike the other indirect branch prediction, can steer you anywhere including to the low 4GB.