From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by sourceware.org (Postfix) with ESMTPS id 3D09F385ED40 for ; Thu, 27 Jan 2022 12:24:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D09F385ED40 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3DBEDB82228; Thu, 27 Jan 2022 12:24:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1264EC340E4; Thu, 27 Jan 2022 12:24:17 +0000 (UTC) Date: Thu, 27 Jan 2022 12:24:14 +0000 From: Catalin Marinas To: Szabolcs Nagy Cc: Mark Brown , Jeremy Linton , Will Deacon , "H . J . Lu" , Yu-cheng Yu , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org, Mark Rutland Subject: Re: [PATCH v7 0/4] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20211209111048.GM3294453@arm.com> <101d8e84-7429-bbf1-0271-5436eca0eea2@arm.com> <8550afd2-268d-a25f-88fd-0dd0b184ca23@arm.com> <20220118110255.GC3294453@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220118110255.GC3294453@arm.com> X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 12:24:26 -0000 (Mark posted another series but I'm replying here to clarify some aspects) On Tue, Jan 18, 2022 at 11:02:55AM +0000, Szabolcs Nagy wrote: > The 01/17/2022 17:54, Catalin Marinas wrote: > > On Fri, Jan 07, 2022 at 12:01:17PM +0000, Catalin Marinas wrote: > > > I think we can look at this from two angles: > > > > > > 1. Ignoring MDWE, should whoever does the original mmap() also honour > > > PROT_BTI? We do this for static binaries but, for consistency, should > > > we extend it to dynamic executable? > > > > > > 2. A 'simple' fix to allow MDWE together with BTI. > > > > Thinking about it, (1) is not that different from the kernel setting > > PROT_EXEC on the main executable when the dynamic loader could've done > > it as well. There is a case for making this more consistent: whoever > > does the mmap() should use the full attributes. > > Yeah that was my original idea that it should be consistent. > One caveat is that protection flags are normally specified > in the program header, but the BTI marking is in > PT_GNU_PROPERTY which is harder to get to, so glibc does not > try to get it right for the initial mapping either: it has > to re-mmap or mprotect. (In principle we could use read > syscalls to parse the ELF headers and notes before mmap, > but that's more complicated with additional failure modes.) > > i.e. if (2) is fixed then mprotect can be used for library > mapping too which is simpler than re-mmap. I lost track of the userspace fixes here, was glibc changed to attempt a re-mmap of the dynamic libraries instead of mprotect()? It looks like (2) is a simpler fix and (1) could still be added for consistency, it's complementary. > > Question for the toolchain people: would the compiler ever generate > > relocations in the main executable that the linker needs to resolve via > > an mprotect(READ|WRITE) followed by mprotect(READ|EXEC)? If yes, we'd > > better go for a proper MDWE implementation in the kernel. > > There is some support for text relocations in glibc, but it's not > expected to be common (e.g. it is a bug if a distro binary has it). Thanks for the clarification. -- Catalin