From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751698AbeBVV7p (ORCPT ); Thu, 22 Feb 2018 16:59:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:41920 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbeBVV7o (ORCPT ); Thu, 22 Feb 2018 16:59:44 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AB01421796 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AH8x224lqp6iBq2pmdt1fEYxFpXXYvqx7t0d0og6nqVbb+pj/A1+ZkZf6/W+OfynnEyGbVkK7G+Txyjg4+moL1kux4o= MIME-Version: 1.0 In-Reply-To: References: <20180222203651.B776810C@viggo.jf.intel.com> <20180222203658.80705136@viggo.jf.intel.com> <93613F56-C778-4EA0-8945-A0B8ABC1A5FD@vmware.com> From: Andy Lutomirski Date: Thu, 22 Feb 2018 21:59:22 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 04/10] x86/espfix: use kernel-default PTE mask To: Dave Hansen Cc: Nadav Amit , "linux-kernel@vger.kernel.org" , "aarcange@redhat.com" , "luto@kernel.org" , "torvalds@linux-foundation.org" , "keescook@google.com" , "hughd@google.com" , "jgross@suse.com" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 22, 2018 at 9:30 PM, Dave Hansen wrote: > On 02/22/2018 01:27 PM, Nadav Amit wrote: >> Dave Hansen wrote: >>> From: Dave Hansen >>> In creating its page tables, the espfix code masks its PGTABLE_PROT >>> value with the supported mask: __supported_pte_mask. This ensures >>> that unsupported bits are not set in the final PTE. But, it also >>> sets _PAGE_GLOBAL which we do not want for PTE. Use >>> __default_kernel_pte_mask instead which clears _PAGE_GLOBAL for PTI. >> >> Can you please explain what is your concern? Exposing more gadgets for >> speculative ROP attacks? >> >> Or is it a general rule of not exposing any kernel code &data more than >> absolutely necessary? > > I think it's good practice to just expose only the *minimal* amount of > data necessary. It's easier to audit and less likely to expose things > accidentall. But espfix64 is geniunely global. I'm confused.