Received: by 10.223.185.116 with SMTP id b49csp998479wrg; Fri, 16 Feb 2018 10:32:37 -0800 (PST) X-Google-Smtp-Source: AH8x2267EApruWXfNSDdqksxYAffbi9hDykJEwOvItzx0xR3bJ+U0ByUR9op0ygPvvif4sBdavib X-Received: by 10.99.176.15 with SMTP id h15mr5904481pgf.374.1518805957246; Fri, 16 Feb 2018 10:32:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518805957; cv=none; d=google.com; s=arc-20160816; b=QBl4pZFOJgcbeXwORGc9xkhIz4chXkvM/Hbfop7isvEBbakJovLFlB0Q1k5kxh4WBK Xj+Wfh2cfayAYsobM83eep+QuAnACyNPCOyM6cZq+V50AzgQhMFasmUjNTGDlz+je7Gw pIIcaXbv7O9ydpaN5N3nT8PRIoKLhpJGYIav9Gj7x4a2NSBMIhLnmQkeFaTwCogdwuk1 skLt3KtYrYLx6HG20VJtKuYH8nZokzqJiddx+N+703oSk/iF9nbv7iFFn/zwU90ru7uy wTlThfhMxz+RIA075P6D8Bm2HZS4NYCgXISM01c/o46olGt2w8ofC764XljP+B444PLv tuMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=M6AUn3pyN0USKTXwHMAeAYKxKTE5P1ltkLUm6KX3y8g=; b=AUrOysNunyCYXk/GRSz4zGEE4Xffba0ZkDFpnmYk8yd2LbjUiyjhwDvhdqadInyJau PRyqm7uMMRfFCXd/RrEAzSKHRtrp4xJS8oqaDoGVhy2PLBst26P/WU3S+duc6ISm2xRW mNgsgPDw18/GBXEsv5A8J1Rvqm+O+H6UjZNJCD76/fCSWe2i4UQsfJCPfIGoqHHz4yBV trjh2OOqBIs/APdk8kLu0I0hO4AG8wTfKZm4pBRrQy3dC7y8zJVTXA0fq82adIz4EafN O+QjSl/wZqDJoIofNaGzlORzr+Fh2zWzA/cuu0cLQl+G2lnXHqO5hLDVYOlOvbIbK0GH lKGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IuVcrfF6; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1si7998889pfg.288.2018.02.16.10.32.22; Fri, 16 Feb 2018 10:32:37 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IuVcrfF6; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756857AbeBPAs2 (ORCPT + 99 others); Thu, 15 Feb 2018 19:48:28 -0500 Received: from mail-pg0-f50.google.com ([74.125.83.50]:44292 "EHLO mail-pg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756845AbeBPAs0 (ORCPT ); Thu, 15 Feb 2018 19:48:26 -0500 Received: by mail-pg0-f50.google.com with SMTP id j9so1160048pgp.11 for ; Thu, 15 Feb 2018 16:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M6AUn3pyN0USKTXwHMAeAYKxKTE5P1ltkLUm6KX3y8g=; b=IuVcrfF6owZR8BqjSCRYjIbAdplqnJI9yHm0u+LyjjmGX8+VR+23zUBDjS62sfeUqp iBjMpNzpEzICcHQp87sw6EWyYNoOUlPj73TNgc3bXqbAfMacoKZQLjbqZx1EIxbJA9v4 uDvqMl52lEQjztjwR4uX5pJG39JbiB4OJHqhc7vaBsjUc5rR8qsZQAJvd2qAv0R1i8Ea 5xSbxWq/F0MB51y5svsRZtZ/xEtFnpZvJvATGCSofokiSL6lYes+LDBZ4HY3MVjlsm5y 638mBtOWTLy4uvZ0Mm/TfFHAdigayPFtL/+1as74Q+YRrBkcG1iq9x30aO+MLmI65mM6 Nxbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M6AUn3pyN0USKTXwHMAeAYKxKTE5P1ltkLUm6KX3y8g=; b=Zlh+Pz7hujzbqzBLtbQpCc3f6mlZJEMOBLAs3qC9D4q8iL/wW95eaeItmvKYxJbBae 2dU6Kd40MWYJHAGmVYqC1KA845D9NcReomRYbhDTie0vpcYj3PHS/z/oglULFu+eZwW5 mvL02tpPZwiLWMlcPYMt6Dr+F9KWy4qEPnZHS+d9IXmSWtBk5YYIyjNFv2ok1R/PspUQ 6EDABSXD9uKG0/msa7nCnaDj1+cMqN78GQ+XDZ0NqDQl32Hb8yRrvytylr7e/K+xpZHk IKb29fiLuLN1jaygS8CctlDcUemP7qgnXUMAjsYuoRUS59Ed4FamwmQr4udhJ+6qy/1r bwOw== X-Gm-Message-State: APf1xPBqdERu7295OfNR4fFvBlkHTNnr1/SliW+rSuaPfxZOR7Kv27VE MAk8B4Lfyv4eW+z9E6ILhJM= X-Received: by 10.98.198.1 with SMTP id m1mr4258287pfg.90.1518742106077; Thu, 15 Feb 2018 16:48:26 -0800 (PST) Received: from [10.2.101.129] ([208.91.2.2]) by smtp.gmail.com with ESMTPSA id k7sm34117177pgt.20.2018.02.15.16.48.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 16:48:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode From: Nadav Amit In-Reply-To: <9a825978-fe69-1c10-0da0-0c67dbb9b232@linux.intel.com> Date: Thu, 15 Feb 2018 16:48:23 -0800 Cc: Ingo Molnar , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Willy Tarreau , x86@kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A2A000F-D39E-40A6-8C01-58344F1034DD@gmail.com> References: <20180215163602.61162-1-namit@vmware.com> <27a0082c-fadb-792a-740e-70932d51f1b5@linux.intel.com> <91CEEFA7-86C8-4731-BC7E-6AF5CC3A1BA4@gmail.com> <9a825978-fe69-1c10-0da0-0c67dbb9b232@linux.intel.com> To: Dave Hansen X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen wrote: > On 02/15/2018 04:25 PM, Nadav Amit wrote: >> Dave Hansen wrote: >>=20 >>> 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. >>>=20 >>> Do you mean you don't fully understand how PTI gives SMEP-like = behavior >>> on non-SMEP hardware? >>=20 >> No. I understand how it provide SMEP-like behavior, and I understand = the value >> of SMEP by itself. >>=20 >> 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. >=20 > There are two problems: one is that regardless of Meltdown/Spectre, = SMEP > is valuable. It's valuable to everything, compatibility-mode or not. >=20 > 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. Thanks for the explanation. Based on Linus response, I guess this series = is nak=E2=80=99d, but still thanks for your patience. I suspected the RSB might be the reason but it seemed to me that all the = ROP opportunities are still there, so I assumed it is not a reason. Anyhow, thanks again.