Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp277434yba; Thu, 18 Apr 2019 00:48:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqyIrrCE6jFKUa08UMx2HrIeZYC2dOE9qPkXswXEgb2tJViJocEDgr1gta82N7h4DAgmp0hX X-Received: by 2002:a62:6fc6:: with SMTP id k189mr76072086pfc.154.1555573715159; Thu, 18 Apr 2019 00:48:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555573715; cv=none; d=google.com; s=arc-20160816; b=Bp1yEnzO70tRI7E2oVbFQWnIEZz4MA+BivypspGIfrM5FtiX9uqO/jclNC6bWzHWtd pvS7hIMDvDgsOroX4TtZWw4zU9/c/FfpMgcwUAX1olH0baiN3SH1ZU/X1Rudv+p/qy+2 Xt6QvFfyzmLNql8wSfDH1TqJ5aHYDIiX06peUEST9QndTcl9f8WoLCQtlWRIkMc0lO5b t9PYYIX+BEQu62LUbDRBfxWPI3693dFEFGCj1Mnh50ObPxfrqybR29h+X7q0iUQd6AEL 3gvXVUQGn32KqEGddm1WyXN5VNyhj8Lau+AzudhA8RX/AV7YJrEXZF+34YVgQzORwkY2 bOww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IVzHmXRqIoHomywgqAqb9JQdOxfcYsfsLDDKG5NiUPs=; b=DZVF2x+5kaRS0gVCvfnV488M//9tXCLo8Z2IZNxT0HURkVTMP3KEqW7q1swFXzs339 R2XySScxm8I7eU6v1s1wBlkYUzG8q99/rrVqRbvOArqH8OkRLjnxODWUZUe1kiSvY2NM s2og0XYWQQKeI1XHeUmNRIXzGEhQoJMujWNZG3FcLJKExk7xx4AEVTkXAF8ax9MoW9qr BKAiugmiqvyClnq1r5MCkuDsS2vIFO3SCyoRagJAyBGvpE53iopByT8so58Pd6Z4grYR x6zsCobREp4XEW5MQ/IFFH4KNT7JNQnfDRU2GViDIN96/Z84N2rppMn9rUQTiEw++4c4 pnog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=GoLXHT0W; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si1389292plo.40.2019.04.18.00.48.20; Thu, 18 Apr 2019 00:48:35 -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; dkim=pass header.i=@chromium.org header.s=google header.b=GoLXHT0W; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388212AbfDRHpi (ORCPT + 99 others); Thu, 18 Apr 2019 03:45:38 -0400 Received: from mail-vs1-f67.google.com ([209.85.217.67]:39991 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728074AbfDRHph (ORCPT ); Thu, 18 Apr 2019 03:45:37 -0400 Received: by mail-vs1-f67.google.com with SMTP id f22so663269vso.7 for ; Thu, 18 Apr 2019 00:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IVzHmXRqIoHomywgqAqb9JQdOxfcYsfsLDDKG5NiUPs=; b=GoLXHT0Wp02nqf3Yl0uJh8Hs9C93SMrJT26BjOERdLWwC6r1PQvnCSKbaXFVlbBn47 tT97BpPB+z7apCEEjjit9SbOJ29njjA6wldiv1hA5Tzv+oUKtVQFPceZPE0cmuJdZGH1 ztV3okKSL2gkLcd8/+4HiHVvJXEbeyWWPELPc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IVzHmXRqIoHomywgqAqb9JQdOxfcYsfsLDDKG5NiUPs=; b=iZVTFqlzljrVChwNNf7Tcfp+xD81RZhWtpwEr+W7pkwghHgl+UNkzYUjShqdE8tXsF ldjHtSMCLakPpuzH6zTtKuQWyLVuo54nk7RQEz3RgiuBpq6u8YdYdANE2G10lefwPO3f pc/zsc3Xe1C4sC1iIRM5WXU7+3WNgNlydiefb6zaScFkqN61UyrDEcxGuyDC535fLdDS RjDthIdEGg4AgMmZUx6NbvE9DmZnC4XhYroXDR9PFbJDf9BesKyRSPXIhrfqFCVUgC/W 5eYSeFu3pgAkzz4wNbhaRrhJ3/9KQAKsU/XHfnI8rULJZcrRquTNE6bl5hmQwXnqW8YC HIDw== X-Gm-Message-State: APjAAAUrHAVHAXDrj6RFRkPcuj2AqIE4MSkPb0RKMcb2x2x3BB4donMN hmCSCI8DARPGppL0vKni8O6ro7ZO4dM= X-Received: by 2002:a67:844d:: with SMTP id g74mr52079013vsd.40.1555573535092; Thu, 18 Apr 2019 00:45:35 -0700 (PDT) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com. [209.85.221.181]) by smtp.gmail.com with ESMTPSA id o126sm367467vke.55.2019.04.18.00.45.33 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 00:45:34 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id s63so264920vkg.10 for ; Thu, 18 Apr 2019 00:45:33 -0700 (PDT) X-Received: by 2002:a1f:7245:: with SMTP id n66mr38481298vkc.40.1555573533181; Thu, 18 Apr 2019 00:45:33 -0700 (PDT) MIME-Version: 1.0 References: <1462963502-11636-1-git-send-email-hecmargi@upv.es> In-Reply-To: <1462963502-11636-1-git-send-email-hecmargi@upv.es> From: Kees Cook Date: Thu, 18 Apr 2019 02:45:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86_64: Disabling read-implies-exec when the stack is executable To: Hector Marco-Gisbert Cc: LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Brian Gerst , Andy Lutomirski , Borislav Petkov , Huaitong Han , Ismael Ripoll Ripoll , Kernel Hardening , Jason Gunthorpe , Andi Kleen , Mark Rutland Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 11, 2016 at 5:45 AM Hector Marco-Gisbert wrote: > > The READ_IMPLIES_EXEC personality was removed in 2005 for 64-bit processes, > (commit a3cc2546a54361b86b73557df5b85c4fc3fc27c3 form history.git). > > But it's still possible to have all readable areas with EXEC permissions by > setting the stack as executable in 64-bit ELF executables (also in 32-bit). > > This is because the macro elf_read_implies_exec() does not distinguish > between 32 and 64-bit executables: when the stack is executable then the > read-implies-exec personality is set (enabled) to the process. > > We think that this is not a desirable behaviour, maybe read-implies-exec > could be used via personality but not by setting the stack as executable in > the ELF. > > For x86_64 processes, is there any reason to disable read-implies-exec > personality and at the same time enable it when the stack is executable ? > > With this patch it's no longer possible to enable the read-implies-exec on > the process by setting the stack as executable in the PT_GNU_STACK on > x86_64 executables. > > Regarding 32-bits processes, is there any reason to enable > read-implies-exec by setting the stack as executable instead of using the > personality on X86_32 or when emulating IA32 on X86_64 ? > > If not, I could re-send the patch which removes this possibility. > > > Signed-off-by: Hector Marco-Gisbert > Acked-by: Ismael Ripoll Ripoll > --- > arch/x86/include/asm/elf.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h > index 15340e3..87fd15e 100644 > --- a/arch/x86/include/asm/elf.h > +++ b/arch/x86/include/asm/elf.h > @@ -271,8 +271,8 @@ extern int force_personality32; > * An executable for which elf_read_implies_exec() returns TRUE will > * have the READ_IMPLIES_EXEC personality flag set automatically. > */ > -#define elf_read_implies_exec(ex, executable_stack) \ > - (executable_stack != EXSTACK_DISABLE_X) > +#define elf_read_implies_exec(ex, executable_stack) \ > + (mmap_is_ia32() ? (executable_stack != EXSTACK_DISABLE_X) : 0) > > struct task_struct; > > -- > 1.9.1 > *thread necromancy* I'd still like to see this get landed. READ_IMPLIES_EXEC is way too powerful (it impacts, for example, mmap() regions of device driver memory, forcing drivers to not be able to disallow VM_EXEC[1]). The only case it could break is on an AMD K8 (Athlon only, I assume?), which seems unlikely to have a modern kernel run on it. If there is still concern, then we could just test against the NX CPU feature: diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h index 69c0f892e310..367cd36259a4 100644 --- a/arch/x86/include/asm/elf.h +++ b/arch/x86/include/asm/elf.h @@ -280,10 +280,12 @@ 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 when + * a CPU did not support NX or is using a 32-bit memory layout. */ -#define elf_read_implies_exec(ex, executable_stack) \ - (executable_stack != EXSTACK_DISABLE_X) +#define elf_read_implies_exec(ex, executable_stack) \ + (mmap_is_ia32() || !(__supported_pte_mask & _PAGE_NX) ? \ + (executable_stack != EXSTACK_DISABLE_X) : 0) struct task_struct; Additionally, I think architectures that always had NX (arm64) should entirely remove their elf_read_implies_exec() macro (defaulting to the removal of the stack-marking-based READ_IMPLIES_EXEC enabling): diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h index 6adc1a90e7e6..87c2dd468eea 100644 --- a/arch/arm64/include/asm/elf.h +++ b/arch/arm64/include/asm/elf.h @@ -107,8 +107,6 @@ */ #define elf_check_arch(x) ((x)->e_machine == EM_AARCH64) -#define elf_read_implies_exec(ex,stk) (stk != EXSTACK_DISABLE_X) - #define CORE_DUMP_USE_REGSET #define ELF_EXEC_PAGESIZE PAGE_SIZE Thoughts? -Kees [1] https://lkml.kernel.org/r/20190418055759.GA3155@mellanox.com -- Kees Cook