From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516587068; cv=none; d=google.com; s=arc-20160816; b=maHvQoMG6XoY3XOKWmm/atJIjn+/CzWHYcwVUPiBEWquNfLwDJvnhTLtbOhPG28rXc MUhGiYoB+o8ms3CrIR8q8Wr4gmIq9G017g98WmBrZeMbj318oiR32wCf92yGsxpXZToN YzvbAJqACMihznDsu1BxzsFsEFUclOa3/knajvRnwrd+BxJd6NnVLKOVoILY7vBrFxeO y173ZV32/h0pJHErhVB6mVk2atdT5uTXcx6TKRhPOMYoHtaVHxL/66hC1jvG8uNXFF6C VWRhbIoKlwoy4lbGbzUYlgBDiVCWWg1uB5anNvCXEUkDjG8oGqaG1djeS5BSdZJYfvru sTtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:sender:mime-version:dkim-signature :arc-authentication-results; bh=NoC+pqptOHt//GwClQlYa0XcRaQhL24zlneaW2s2kZg=; b=yUZUaXirHJ4GfCWyttDPyC4nc1ZftRz5ppSW/DgwoxLstQ448ykppC6XJps6+1JvSj zLu5pTUoh0Os/Zp7Z+SKcqYfy1lwX6O9DQIRCphimw6B8YWdgJ76Qlc/tKPnRF4UBXku By3Z2LLqU+gBVMpAd/MFoYLidGpzGsBkKwbYMVjqNIljIZDESIHXxtOMH/Boa83gIUdq J3aFjF4BxX8IamXacF3j3JyeqcAm7il8W/fxkf0xfAM55A/lxOsA8uJvvMaMrfDs+dnQ lRq63ppWaUiI5H8zpV6DRpXJJGIhF46UXq5mpTiA4c5aTJN9VsP/EmJCeSsrCM1Rsl2v r7og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lPNDXAuW; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lPNDXAuW; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com X-Google-Smtp-Source: AH8x225cbegRyuWR5N7H0G+owXrRVtgokBqg75WIWWO0c07/Klq8ikDATUZPIMM3MIWQwsoH4DSKmuSeflYwqr9mk4I= MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <9CF1DD34-7C66-4F11-856D-B5E896988E16@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> From: Linus Torvalds Date: Sun, 21 Jan 2018 18:11:07 -0800 X-Google-Sender-Auth: cYzZpOzd7AJu-XIr1LsHw8mGR9o Message-ID: Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 To: Nadav Amit 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841591470697?= X-GMAIL-MSGID: =?utf-8?q?1590256802011013772?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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. > > It does seem that segmentation provides sufficient protection from Meltdo= wn. > 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. Interesting. It might not be entirely reliable for all microarchitectures, though. > So my question: wouldn=E2=80=99t it be much more efficient to use segment= ation > protection for x86-32, and allow users to choose whether they want SMEP-l= ike > protection if needed (and then enable PTI)? 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). 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). And we should check with Intel that segment limit checking really is guaranteed to be done before any access. Too bad x86-64 got rid of the segments ;) Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id 91D29800D8 for ; Sun, 21 Jan 2018 21:11:09 -0500 (EST) Received: by mail-io0-f198.google.com with SMTP id n19so8441029iob.7 for ; Sun, 21 Jan 2018 18:11: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 u185sor3913317itf.144.2018.01.21.18.11.08 for (Google Transport Security); Sun, 21 Jan 2018 18:11:08 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <9CF1DD34-7C66-4F11-856D-B5E896988E16@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> From: Linus Torvalds Date: Sun, 21 Jan 2018 18:11:07 -0800 Message-ID: Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Nadav Amit 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 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. > > It does seem that segmentation provides sufficient protection from Meltdo= wn. > 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. Interesting. It might not be entirely reliable for all microarchitectures, though. > So my question: wouldn=E2=80=99t it be much more efficient to use segment= ation > protection for x86-32, and allow users to choose whether they want SMEP-l= ike > protection if needed (and then enable PTI)? 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). 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). And we should check with Intel that segment limit checking really is guaranteed to be done before any access. Too bad x86-64 got rid of the segments ;) Linus -- 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