From patchwork Tue Apr 23 18:51:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 10913667 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CA95D1515 for ; Tue, 23 Apr 2019 18:51:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BA0D728334 for ; Tue, 23 Apr 2019 18:51:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A8BF62890A; Tue, 23 Apr 2019 18:51:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SORTED_RECIPS autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 1951228334 for ; Tue, 23 Apr 2019 18:51:44 +0000 (UTC) Received: (qmail 23711 invoked by uid 550); 23 Apr 2019 18:51:43 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 23676 invoked from network); 23 Apr 2019 18:51:42 -0000 Date: Tue, 23 Apr 2019 11:51:28 -0700 From: akpm@linux-foundation.org To: a.p.zijlstra@chello.nl, hecmargi@upv.es, hpa@zytor.com, jgg@mellanox.com, keescook@chromium.org, kernel-hardening@lists.openwall.com, luto@amacapital.net, mark.rutland@arm.com, mingo@elte.hu, mm-commits@vger.kernel.org, tglx@linutronix.de Subject: + binfmt_elf-update-read_implies_exec-logic-for-modern-cpus.patch added to -mm tree Message-ID: <20190423185128.6SVhFqa1-%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Virus-Scanned: ClamAV using ClamSMTP The patch titled Subject: binfmt_elf: Update READ_IMPLIES_EXEC logic for modern CPUs has been added to the -mm tree. Its filename is binfmt_elf-update-read_implies_exec-logic-for-modern-cpus.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/binfmt_elf-update-read_implies_exec-logic-for-modern-cpus.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elf-update-read_implies_exec-logic-for-modern-cpus.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kees Cook Subject: binfmt_elf: Update READ_IMPLIES_EXEC logic for modern CPUs The READ_IMPLIES_EXEC work-around was designed for old CPUs lacking NX (to have the visible permission flags on memory regions reflect reality: they are all executable), and for old toolchains that lacked the ELF PT_GNU_STACK marking (under the assumption than toolchains that couldn't even specify memory protection flags may have it wrong for all memory regions). This logic is sensible, but was implemented in a way that equated having a PT_GNU_STACK marked executable as being as "broken" as lacking the PT_GNU_STACK marking entirely. This is not a reasonable assumption for CPUs that have had NX support from the start (or very close to the start). This confusion has led to situations where modern 64-bit programs with explicitly marked executable stack are forced into the READ_IMPLIES_EXEC state when no such thing is needed. (And leads to unexpected failures when mmap()ing regions of device driver memory that wish to disallow VM_EXEC[1].) To fix this, elf_read_implies_exec() is adjusted on arm64 (where NX has always existed and all toolchains include PT_GNU_STACK), and x86 is adjusted to handle this combination of possible outcomes: CPU: | lacks NX | has NX, ia32 | has NX, x86_64 | ELF: | | | | ------------------------------|------------------|------------------| missing GNU_STACK | needs RIE | needs RIE | no RIE | GNU_STACK == RWX | needs RIE | no RIE: stack X | no RIE: stack X | GNU_STACK == RW | needs RIE | no RIE: stack NX | no RIE: stack NX | This has the effect of making binfmt_elf's EXSTACK_DEFAULT actually take on the correct architecture default of being non-executable on arm64 and x86_64, and being executable on ia32. [1] https://lkml.kernel.org/r/20190418055759.GA3155@mellanox.com Link: http://lkml.kernel.org/r/20190423181210.GA2443@beast Signed-off-by: Kees Cook Suggested-by: Hector Marco-Gisbert Cc: Jason Gunthorpe Cc: Thomas Gleixner Cc: Andy Lutomirski Cc: Kernel Hardening Cc: Mark Rutland Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Peter Zijlstra Signed-off-by: Andrew Morton --- arch/arm64/include/asm/elf.h | 9 ++++++++- arch/x86/include/asm/elf.h | 24 +++++++++++++++++++++--- 2 files changed, 29 insertions(+), 4 deletions(-) --- a/arch/arm64/include/asm/elf.h~binfmt_elf-update-read_implies_exec-logic-for-modern-cpus +++ a/arch/arm64/include/asm/elf.h @@ -107,7 +107,14 @@ */ #define elf_check_arch(x) ((x)->e_machine == EM_AARCH64) -#define elf_read_implies_exec(ex,stk) (stk != EXSTACK_DISABLE_X) +/* + * 64-bit processes should not automatically gain READ_IMPLIES_EXEC. Only + * 32-bit processes without PT_GNU_STACK should trigger READ_IMPLIES_EXEC + * out of an abundance of caution against ancient toolchains not knowing + * how to mark memory protection flags correctly. + */ +#define elf_read_implies_exec(ex, stk) \ + (is_compat_task() && stk == EXSTACK_DEFAULT) #define CORE_DUMP_USE_REGSET #define ELF_EXEC_PAGESIZE PAGE_SIZE --- a/arch/x86/include/asm/elf.h~binfmt_elf-update-read_implies_exec-logic-for-modern-cpus +++ a/arch/x86/include/asm/elf.h @@ -280,10 +280,28 @@ extern u32 elf_hwcap2; /* * An executable for which elf_read_implies_exec() returns TRUE will - * have the READ_IMPLIES_EXEC personality flag set automatically. + * have the READ_IMPLIES_EXEC personality flag set automatically. This + * is needed either to show the truth about a memory mapping (i.e. CPUs + * that lack NX have all memory implicitly executable, so this makes + * sure that the visible permissions reflect reality), or to deal with + * old toolchains on new CPUs. Old binaries entirely lacking a GNU_STACK + * indicate they were likely built with a toolchain that has no idea about + * memory permissions, and so we must default to the lowest reasonable + * common denominator for the architecture: on ia32 we assume all memory + * to be executable by default, and on x86_64 we assume all memory to be + * non-executable by default. + * + * CPU: | lacks NX | has NX, ia32 | has NX, x86_64 | + * ELF: | | | | + * ------------------------------|------------------|------------------| + * missing GNU_STACK | needs RIE | needs RIE | no RIE | + * GNU_STACK == RWX | needs RIE | no RIE: stack X | no RIE: stack X | + * GNU_STACK == RW | needs RIE | no RIE: stack NX | no RIE: stack NX | + * */ -#define elf_read_implies_exec(ex, executable_stack) \ - (executable_stack != EXSTACK_DISABLE_X) +#define elf_read_implies_exec(ex, stk) \ + (!(__supported_pte_mask & _PAGE_NX) ? 1 : \ + (mmap_is_ia32() && stk == EXSTACK_DEFAULT)) struct task_struct;