From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: * X-Spam-Status: No, score=1.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C576C10F03 for ; Thu, 25 Apr 2019 05:45:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 60EA9214AE for ; Thu, 25 Apr 2019 05:45:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EVx8uY5J"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E0OEl58k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 60EA9214AE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KRPaDHX+O4wO5X+64Nt/+HrppJzIS/vSCYdVwTFK9uQ=; b=EVx8uY5Jk8nmjL istXNdbJUAKfcPFqMHfBiOkvSr2lJ7E8NNHVRklPgL8dHsVvcEqYzxQ+LD88UpwGSSjDpqs56/sAY ZVqU0/U1ezCyqJs0/J93QCT1duOJPPkYNQeupaCl/KwhJmzlCbNShKPpNRCVQClWqTdpWo0jk3gMJ e69GS/ZVONYG8N9tITVjLYcMvZXh7YmY4+9NAxjLQYqpWah55WT8zimWB6Fu6BnaB1QGRGfBoclyM 95AwwSr3IaJz02wZvZWmCPQ+4Rm9zmWzr/fINdAn08C+NelFlvIWyqR6z7TpDPuik0DW7niSpRGtr egweTjMCM5x4nbZtnGYA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJX9n-000138-A5; Thu, 25 Apr 2019 05:42:51 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJX9k-00012l-CU for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2019 05:42:49 +0000 Received: by mail-wm1-x341.google.com with SMTP id w15so8554144wmc.3 for ; Wed, 24 Apr 2019 22:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=mFaGk17zBVaZD9Ik72FhzKJm7fKCzkWf7LsFsFGH3Ms=; b=E0OEl58kIDsDj3OX2Dxz/ZJCU/A+rpc8cYFyHBQXnHAxBcXGOj/bEBKrHoQSCGcUT4 v0ikdnhi3FemkJQvj8NpCcC+GlafSskKHA4YY39/3pGrJj6e7e/HKXn1EPR+PnMPQrQW YZfuZvlKIpsuQwB0UOo2277taH/NpcellJk8VsVuieZ4Bw1lzmHkgpMuZkCCArTciLP9 2adLyAGwoTskYFyD7XpCpVZFebr5PvJ7kJCO0+UrBwPsqIQI5kha64IuqF8fUgBjRiSs BC5gLDWl3OaxuRCQQXfX0HM/7bOAkTThD9FPRS3K0nFBEOmx/MwbQyJqmEakQmU/3Kz1 Dfvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=mFaGk17zBVaZD9Ik72FhzKJm7fKCzkWf7LsFsFGH3Ms=; b=K3jyHTVsQ5RENnsXlFC2Z+KNIsbZEaOKN9QGrbEk2S8jbcgfrDhSxvXa/fpYoUt0/E PcjbK7dACgAirIPKr8VYMbSEhM1ngIo1T4Y23LsRZFvppqJpu3yHBbmq858sG29dZUi5 IuRwOM8do04dl2ENSxNuAcJbrTiYzL9mbnDbosD1gmNyilpNJoXjB/B8W1xewemnI4Nm +ca2MwKQMDfVjVtsT2KYJrKp1m1qCRXblje2HY+2ISskBvDG5F5HascxitQsNXq90JgF 9BrzEz3kjEdKsYL/UcrwMWKRzNRw6yY1/hKLrXawkQjxoJdvv5AdjtzCY9gqQM7nUdTm 8K8w== X-Gm-Message-State: APjAAAUgZFspKysBPxfHNysm7o9TS3UPtpEH12mmta9BnHinfLGzxjjc n6rqws496tqwEdfVY4unN4g= X-Google-Smtp-Source: APXvYqwE4UYOfn07X6aedJFEOECNgVPLggSoZvRObm5IhchWEEMZ3b3FtXr+bnFj+EjlCMggfhFPgQ== X-Received: by 2002:a05:600c:d4:: with SMTP id u20mr2060638wmm.88.1556170966473; Wed, 24 Apr 2019 22:42:46 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id m8sm10106121wrx.48.2019.04.24.22.42.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Apr 2019 22:42:45 -0700 (PDT) Date: Thu, 25 Apr 2019 07:42:42 +0200 From: Ingo Molnar To: Kees Cook Subject: Re: [PATCH v2] binfmt_elf: Update READ_IMPLIES_EXEC logic for modern CPUs Message-ID: <20190425054242.GA7816@gmail.com> References: <20190424203408.GA11386@beast> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190424203408.GA11386@beast> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190424_224248_425522_765C6AE3 X-CRM114-Status: GOOD ( 17.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Stephen Rothwell , Peter Zijlstra , Arnd Bergmann , Marc Gonzalez , Hector Marco-Gisbert , x86@kernel.org, Will Deacon , linux-kernel@vger.kernel.org, Andy Lutomirski , Jason Gunthorpe , Borislav Petkov , Catalin Marinas , Kernel Hardening , Andrew Morton , Linus Torvalds , Thomas Gleixner , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Kees Cook wrote: > 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 that 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 toolchains have implemented PT_GNU_STACK for a while), > 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. Just to make clear, is the change from the old behavior, in essence: CPU: | lacks NX | has NX, ia32 | has NX, x86_64 | ELF: | | | | ------------------------------|------------------|------------------| missing GNU_STACK | exec-all | exec-all | exec-none | - GNU_STACK == RWX | exec-all | exec-all | exec-all | + GNU_STACK == RWX | exec-all | exec-stack | exec-stack | GNU_STACK == RW | exec-all | exec-none | exec-none | correct? Also note that in addition to marking the changes clearly, I also edited the table to be less confusing and more assertive: 'exec-all' : all user mappings are executable 'exec-none' : only PROT_EXEC user mappings are executable 'exec-stack': only the stack and PROT_EXEC user mappings are executable Is this correct? (Please double check the edited table.) In particular, what is the policy for write-only and exec-only mappings, what does read-implies-exec do for them? Also, it would be nice to define it precisely what 'stack' means in this context: it's only the ELF loader defined process stack - other stacks such as any thread stacks, signal stacks or alt-stacks depend on the C library - or does the kernel policy extend there too? I.e. it would be nice to clarify all this, because it's still rather confusing and ambiguous right now. Thanks, Ingo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel