Received: by 10.192.165.148 with SMTP id m20csp762713imm; Fri, 20 Apr 2018 15:28:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/VWJIF+rvIVv35kDCVQfFP0nupMAQZepRzIfNBYqgH8LEFDdAAFQqYbftc4ODyChaK3LJz X-Received: by 10.99.152.84 with SMTP id l20mr9601130pgo.16.1524263292191; Fri, 20 Apr 2018 15:28:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524263292; cv=none; d=google.com; s=arc-20160816; b=jwMPHdHO4cONm6zCOT1DSlqP/vTom029gWmCw/uUyOYLJ/9PS6YZp45KqrBoWYInFQ dfWCQz/v4DoRXY67CGlJdHPsAb6bteVjUFXipsYP7G0r+BBSxP59byU5d9qfMlaMl+4K uK6JvXoaVjWxMXsX/Km0o/W28eND6V2Ja9JpVf36WyTCnG8rRvN+wbvD1Alys5sZ+PHN P6P2MrC9IfMZ2/rLMtdEiFatn2f5MMyGxROAYq+wbUiSgU0o8UwS1H4bLVR0sWPE/mKu XQZrnWjtGx/3Ot5Z3hEe9b2oRmsLcykmOheIcB60ZajyiiENW4aKX2RvPJxHVghbBUOW WStg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject:arc-authentication-results; bh=cRwneappTf1zk/B3gJ8PFeXKVIOJ37EW016nXcF7XN8=; b=LP3xp55V5QiAD6DmbDTSLwCbiioE2RNBqAv2MUaSWVS4y/1A99qeWgKrppwOCaFuT7 CIn/B3dROgAcKLONn5SnrZXfmPcShhXxyJs0kq0iYcvd42GGmD7aMcMkISI/Mw0TUx5s U+EaxO44ECpKVbuMZ5n6gYNJ8DElWAzgrCFhfdBrjW7AQLRfhavkwY4txrElZS65/SOo gP26T/0U7s85eFDo1eQt7tLZFqQjgJ/9MO27l/hsGvxARiqY4kBPHsqL2ED5oMpey8+o q4I3VidFkwSsIgCDwWorI+uCjmxspBIMB6rFa/RW9ItJedKZ6884JXlDGHQJIL5TJ2tF YLPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l33-v6si6433962pld.512.2018.04.20.15.27.35; Fri, 20 Apr 2018 15:28:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753138AbeDTWYV (ORCPT + 99 others); Fri, 20 Apr 2018 18:24:21 -0400 Received: from mga09.intel.com ([134.134.136.24]:28854 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753057AbeDTWYQ (ORCPT ); Fri, 20 Apr 2018 18:24:16 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2018 15:24:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,303,1520924400"; d="scan'208";a="39172346" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by fmsmga002.fm.intel.com with ESMTP; 20 Apr 2018 15:24:15 -0700 Subject: [PATCH 3/5] x86, pti: reduce amount of kernel text allowed to be Global To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen , keescook@google.com, aarcange@redhat.com, luto@kernel.org, arjan@linux.intel.com, bp@alien8.de, dan.j.williams@intel.com, dwmw2@infradead.org, gregkh@linuxfoundation.org, hughd@google.com, jpoimboe@redhat.com, jgross@suse.com, torvalds@linux-foundation.org, namit@vmware.com, peterz@infradead.org, tglx@linutronix.de From: Dave Hansen Date: Fri, 20 Apr 2018 15:20:23 -0700 References: <20180420222018.E7646EE1@viggo.jf.intel.com> In-Reply-To: <20180420222018.E7646EE1@viggo.jf.intel.com> Message-Id: <20180420222023.1C8B2B20@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees reported to me that I made too much of the kernel image global. It was far more than just text: I think this is too much set global: _end is after data, bss, and brk, and all kinds of other stuff that could hold secrets. I think this should match what mark_rodata_ro() is doing. This does exactly that. We use __end_rodata_hpage_align as our marker both because it is huge-page-aligned and it does not contain any sections we expect to hold secrets. Kees's logic was that r/o data is in the kernel image anyway and, in the case of traditional distributions, can be freely downloaded from the web, so there's no reason to hide it. Signed-off-by: Dave Hansen Reported-by: Kees Cook Fixes: 8c06c7740 (x86/pti: Leave kernel text global for !PCID) Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Dan Williams Cc: David Woodhouse Cc: Greg Kroah-Hartman Cc: Hugh Dickins Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Kees Cook Cc: Linus Torvalds Cc: Nadav Amit Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-mm@kvack.org --- b/arch/x86/mm/pti.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff -puN arch/x86/mm/pti.c~pti-glb-too-much-mapped arch/x86/mm/pti.c --- a/arch/x86/mm/pti.c~pti-glb-too-much-mapped 2018-04-20 14:10:02.164749166 -0700 +++ b/arch/x86/mm/pti.c 2018-04-20 14:10:02.168749166 -0700 @@ -430,12 +430,24 @@ static inline bool pti_kernel_image_glob */ void pti_clone_kernel_text(void) { + /* + * rodata is part of the kernel image and is normally + * readable on the filesystem or on the web. But, do not + * clone the areas past rodata, they might contain secrets. + */ unsigned long start = PFN_ALIGN(_text); - unsigned long end = ALIGN((unsigned long)_end, PMD_PAGE_SIZE); + unsigned long end = (unsigned long)__end_rodata_hpage_align; if (!pti_kernel_image_global_ok()) return; + pr_debug("mapping partial kernel image into user address space\n"); + + /* + * Note that this will undo _some_ of the work that + * pti_set_kernel_image_nonglobal() did to clear the + * global bit. + */ pti_clone_pmds(start, end, _PAGE_RW); } @@ -458,8 +470,6 @@ void pti_set_kernel_image_nonglobal(void if (pti_kernel_image_global_ok()) return; - pr_debug("set kernel image non-global\n"); - set_memory_nonglobal(start, (end - start) >> PAGE_SHIFT); } _