Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756066AbeAORpL (ORCPT + 1 other); Mon, 15 Jan 2018 12:45:11 -0500 Received: from mail-pf0-f181.google.com ([209.85.192.181]:45064 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756078AbeAORpH (ORCPT ); Mon, 15 Jan 2018 12:45:07 -0500 X-Google-Smtp-Source: ACJfBotJfV2SC/Bqr20OP2ckDfYOGPBv2gmqnDmoYnLcMJvpffq/Lw3X+0FdgxFvvokZS3cQkcTiDA== 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: <451AD6CB-74AA-4869-8CB1-8175126C3F0D@vmware.com> Date: Mon, 15 Jan 2018 09:45:04 -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: <3A5624D6-3D7B-4C32-BF97-27A78CBEE14E@amacapital.net> References: <20180114201306.3554-1-namit@vmware.com> <451AD6CB-74AA-4869-8CB1-8175126C3F0D@vmware.com> 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: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. > Regards, > Nadav