From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516588087; cv=none; d=google.com; s=arc-20160816; b=Vs+BPGv22J4lFpjzpSqWd3aPWfaH2yt/CWb1z2ADpzzQoKcBwdEYUZ5g9p+349oigh p4SGjiuymRT9QgJOmXK2Ofp/jn3m4VWRfT1HbA6Go2NMSX65zE7ED7W9/DoFEc37zjmT hdSUXIn8sk/6IqO86UzL6xykRed2shbSZEyj1p92rV0Q5TVJBbcm2nBWPCH6y8S06hHT UQkYJAuVlA6mAA5CorK8bhfBNSUeSQKUExlZKbbo0Vye4g4GPUyqqFmnbQrAklyxgFVn Es6dMejttxJqNsE6Pb/wcMNM1ya2STwM8aC4SsR8ETGhzKIIri/xnTptmJwVsokP4+Z6 +dSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:dkim-signature :arc-authentication-results; bh=OLl64QM8LbaeGqjnje8L5GVJXImcqDoHhXL5etf7jY4=; b=sDSpdRewQNXtyAN4+Ms/lBYWKoNTZTQUYVy0Jon2R7X8/AJbWiwih856cqw8TE/lkA LByon/574yaBZ06CbX6F7LVtQpiXEEVe4irXEFbg0b3eeBa/y6a+ws/GDbeSA7lbnRg0 K4Ma+D+mhGztq3oe4ufdGCfFyZD87XcBrpMBP0bwxadTjEQz5/P/2srIf2E8Imzu67Uo OCMOiLS/qRSbpC9RZXzGWd5Kkgx6mK4G+wWQsFaXAjj8QVAY9CDS0dpSp3kApgY6e5h5 7l76CDnOqFsDJJ1E/Qk2htPWmSmlfFJmPy7QrxLKzOWNGUHHGb9f7wbs8NtK5ZPKhns9 7Uog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZDCsAxaK; spf=pass (google.com: domain of nadav.amit@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZDCsAxaK; spf=pass (google.com: domain of nadav.amit@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com X-Google-Smtp-Source: AH8x225G0CEskJvnAZo3Au4ASimRBSM2HRfw+4HERS0pkur4eDBOe28CC5swxLnfMkbr9w91Hz0zhQ== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 From: Nadav Amit In-Reply-To: Date: Sun, 21 Jan 2018 18:27:59 -0800 Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel Content-Transfer-Encoding: quoted-printable Message-Id: <8B8147E4-0560-456D-BA23-F0037C80C945@gmail.com> References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3273) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841591470697?= X-GMAIL-MSGID: =?utf-8?q?1590257870279572638?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit = wrote: >> I wanted to see whether segments protection can be a replacement for = PTI >> (yes, excluding SMEP emulation), or whether speculative execution = =E2=80=9Cignores=E2=80=9D >> limit checks, similarly to the way paging protection is skipped. >>=20 >> It does seem that segmentation provides sufficient protection from = Meltdown. >> The =E2=80=9Creliability=E2=80=9D test of Gratz PoC fails if the = segment limit is set to >> prevent access to the kernel memory. [ It passes if the limit is not = set, >> even if the DS is reloaded. ] My test is enclosed below. >=20 > Interesting. It might not be entirely reliable for all > microarchitectures, though. >=20 >> So my question: wouldn=E2=80=99t it be much more efficient to use = segmentation >> protection for x86-32, and allow users to choose whether they want = SMEP-like >> protection if needed (and then enable PTI)? >=20 > That's what we did long long ago, with user space segments actually > using the limit (in fact, if you go back far enough, the kernel even > used the base). >=20 > You'd have to make sure that the LDT loading etc do not allow CPL3 > segments with base+limit past TASK_SIZE, so that people can't generate > their own. And the TLS segments also need to be limited (and > remember, the limit has to be TASK_SIZE-base, not just TASK_SIZE). >=20 > And we should check with Intel that segment limit checking really is > guaranteed to be done before any access. Thanks. I=E2=80=99ll try to check with Intel liaison people of VMware = (my employer), yet any feedback will be appreciated. > Too bad x86-64 got rid of the segments ;) Actually, as I noted in a different thread, running 32-bit binaries on x86_64 in legacy-mode, without PTI, performs considerably better than = x86_64 binaries with PTI for workloads that are hit the most (e.g., Redis). By dynamically removing the 64-bit user-CS from the GDT, this mode should = be safe, as long as CS load is not done speculatively. Regards, Nadav= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id 13D13800D8 for ; Sun, 21 Jan 2018 21:28:09 -0500 (EST) Received: by mail-wr0-f198.google.com with SMTP id h38so5663882wrh.11 for ; Sun, 21 Jan 2018 18:28:09 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id c2sor9256731edi.46.2018.01.21.18.28.07 for (Google Transport Security); Sun, 21 Jan 2018 18:28:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 From: Nadav Amit In-Reply-To: Date: Sun, 21 Jan 2018 18:27:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8B8147E4-0560-456D-BA23-F0037C80C945@gmail.com> References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit = wrote: >> I wanted to see whether segments protection can be a replacement for = PTI >> (yes, excluding SMEP emulation), or whether speculative execution = =E2=80=9Cignores=E2=80=9D >> limit checks, similarly to the way paging protection is skipped. >>=20 >> It does seem that segmentation provides sufficient protection from = Meltdown. >> The =E2=80=9Creliability=E2=80=9D test of Gratz PoC fails if the = segment limit is set to >> prevent access to the kernel memory. [ It passes if the limit is not = set, >> even if the DS is reloaded. ] My test is enclosed below. >=20 > Interesting. It might not be entirely reliable for all > microarchitectures, though. >=20 >> So my question: wouldn=E2=80=99t it be much more efficient to use = segmentation >> protection for x86-32, and allow users to choose whether they want = SMEP-like >> protection if needed (and then enable PTI)? >=20 > That's what we did long long ago, with user space segments actually > using the limit (in fact, if you go back far enough, the kernel even > used the base). >=20 > You'd have to make sure that the LDT loading etc do not allow CPL3 > segments with base+limit past TASK_SIZE, so that people can't generate > their own. And the TLS segments also need to be limited (and > remember, the limit has to be TASK_SIZE-base, not just TASK_SIZE). >=20 > And we should check with Intel that segment limit checking really is > guaranteed to be done before any access. Thanks. I=E2=80=99ll try to check with Intel liaison people of VMware = (my employer), yet any feedback will be appreciated. > Too bad x86-64 got rid of the segments ;) Actually, as I noted in a different thread, running 32-bit binaries on x86_64 in legacy-mode, without PTI, performs considerably better than = x86_64 binaries with PTI for workloads that are hit the most (e.g., Redis). By dynamically removing the 64-bit user-CS from the GDT, this mode should = be safe, as long as CS load is not done speculatively. Regards, Nadav= -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org