Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751941AbeAOSEz (ORCPT + 1 other); Mon, 15 Jan 2018 13:04:55 -0500 Received: from mail-pl0-f45.google.com ([209.85.160.45]:39953 "EHLO mail-pl0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751916AbeAOSEw (ORCPT ); Mon, 15 Jan 2018 13:04:52 -0500 X-Google-Smtp-Source: ACJfBosdG4l1ID5sKv+TXSl5KgcRCF6mx62SwM9XVbIIWG1U4oQQMW52HO1r2ybsaQDVHllt9LBajg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI From: Andy Lutomirski X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Mon, 15 Jan 2018 10:04:50 -0800 Cc: LKML , Dave Hansen , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , "w@1wt.eu" Content-Transfer-Encoding: 8BIT Message-Id: References: <20180114201306.3554-1-namit@vmware.com> <451AD6CB-74AA-4869-8CB1-8175126C3F0D@vmware.com> <3A5624D6-3D7B-4C32-BF97-27A78CBEE14E@amacapital.net> To: Nadav Amit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > On Jan 15, 2018, at 9:50 AM, Nadav Amit wrote: > > Andy Lutomirski wrote: > >> >> >>> On Jan 15, 2018, at 9:42 AM, Nadav Amit wrote: >>> >>> Andy Lutomirski wrote: >>> >>>>> On Jan 14, 2018, at 12:13 PM, Nadav Amit wrote: >>>>> >>>>> Currently, when page-table isolation is on to prevent the Meltdown bug >>>>> (CVE-2017-5754), CR3 is always loaded on system-call and interrupt. >>>>> >>>>> However, it appears that this is an unnecessary measure when programs >>>>> run in compatibility mode. In this mode only 32-bit registers are >>>>> available, which means that there *should* be no way for the CPU to >>>>> access, even speculatively, memory that belongs to the kernel, which >>>>> sits in high addresses. >>>> >>>> You're assuming that TIF_IA32 prevents the execution of 64-bit code. It doesn't. >>>> >>>> I've occasionally considered adding an opt-in hardening mechanism to enforce 32-bit or 64-bit execution, but we don't have this now. >>> >>> I noticed it doesn’t. I thought the removing/restoring the __USER_CS >>> descriptor on context switch, based on TIF_IA32, would be enough. >>> modify_ldt() always keeps the descriptor l-bit clear. I will review the >>> other GDT descriptors, and if needed, create two GDTs. Let me know if I >>> missed anything else. >> >> There world need to be some opt-in control, I think, for CRIU if nothing else. >> >> Also, on Xen PV, it's a complete nonstarter. We don't have enough control over the GDT unless someone knows otherwise. But there's no PTI on Xen PV either. >> >>>> Anything like this would also need to spend on SMEP, I think -- the pseudo-SMEP granted by PTI is too valuable to give up on old boxes, I think. >>> >>> If SMEP is not supported, compatibility mode would still require page-table >>> isolation. >>> >>> Thanks for the feedback. I still look for an ack for the basic idea of >>> disabling page-table isolation on compatibility mode. >> >> I'm still not really convinced this is worth it. It will send a bad message and get people to run critical stuff compiled for 32-bit, which has its own downsides. > > I can handle #GP gracefully if __USER_CS is loaded so PTI would be required > again. Doing so would eliminate the need for an opt-in, and preserve the > current semantics. > Not if someone used LAR, a la the sigreturn_32 test. Not necessarily a showstopper, though. You'd also have to figure out how to do PTI per-thread, which Linus doesn't like. See Willy's PTI opt-out thread.