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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 CB3C9C54EEB for ; Mon, 23 Mar 2020 14:40:07 +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 A0EBF20780 for ; Mon, 23 Mar 2020 14:40:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NY407OQj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0EBF20780 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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=Inl9mZy7hq31gegZCV0scyxfaxgl89+uDdA7Yt/WxnA=; b=NY407OQjf/lEL1 8aZLqGs8NbED+0XetFNyYILYZEhGPkGbYrn4EXRyyqcK5WPmktwXKqoZe5MgcYJb58X0h/9dUHiOS Y6PHqU7s9Fg1w+dEZdnLS3d1uHKyWOKjlNNDQoICMl00AZnRkuh46TfJcHlCdLsaJg4gsZWs93inF DP3yecaQLc6bQEvlwyD2OCO17MGxo8q9rSytpb/fLFOJrzKX2WdUqoTDkY7l5NXcZh55wRbvqg6q0 1O9wS9Fxkc0z7wnSLA5q9Ko7dWR9uSlstXQ6VkyW2LoRsoZppggUZCkU2ESgdnpV97ox2vHhnErh8 Aabt2c55PsqTQGv/5YAQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGOFK-0006j0-8v; Mon, 23 Mar 2020 14:40:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGOFG-0006G2-Ab for linux-arm-kernel@lists.infradead.org; Mon, 23 Mar 2020 14:40:03 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 74305FEC; Mon, 23 Mar 2020 07:40:01 -0700 (PDT) Received: from mbp (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B8773F52E; Mon, 23 Mar 2020 07:39:57 -0700 (PDT) Date: Mon, 23 Mar 2020 14:39:55 +0000 From: Catalin Marinas To: Mark Rutland Subject: Re: [PATCH v10 00/13] arm64: Branch Target Identification support Message-ID: <20200323143954.GC4892@mbp> References: <20200316165055.31179-1-broonie@kernel.org> <20200320173945.GC27072@arm.com> <20200323122143.GB4892@mbp> <20200323132412.GD4948@sirena.org.uk> <20200323135722.GA3959@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200323135722.GA3959@C02TD0UTHF1T.local> 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-20200323_074002_475807_A60CBFE6 X-CRM114-Status: GOOD ( 22.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Elliott , Szabolcs Nagy , Andrew Jones , Amit Kachhap , Vincenzo Frascino , Will Deacon , linux-arch@vger.kernel.org, Marc Zyngier , Eugene Syromiatnikov , Peter Zijlstra , "H . J . Lu " , Yu-cheng Yu , Kees Cook , Arnd Bergmann , Jann Horn , Richard Henderson , Kristina =?utf-8?Q?Mart=C5=A1enko?= , Mark Brown , Alexander Viro , Thomas Gleixner , nd@arm.com, linux-arm-kernel@lists.infradead.org, Florian Weimer , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Sudakshina Das 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 On Mon, Mar 23, 2020 at 01:57:22PM +0000, Mark Rutland wrote: > On Mon, Mar 23, 2020 at 01:24:12PM +0000, Mark Brown wrote: > > On Mon, Mar 23, 2020 at 12:21:44PM +0000, Catalin Marinas wrote: > > > On Fri, Mar 20, 2020 at 05:39:46PM +0000, Szabolcs Nagy wrote: > > > > > +int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state, > > > + bool has_interp, bool is_interp) > > > +{ > > > + if (is_interp != has_interp) > > > + return prot; > > > + > > > + if (!(state->flags & ARM64_ELF_BTI)) > > > + return prot; > > > + > > > + if (prot & PROT_EXEC) > > > + prot |= PROT_BTI; > > > + > > > + return prot; > > > +} > > > > > At a quick look, for dynamic binaries we have has_interp == true and > > > is_interp == false. I don't know why but, either way, the above code > > > needs a comment with some justification. > > > > I don't really know for certain either, I inherited this code as is with > > the understanding that this was all agreed with the toolchain and libc > > people - the actual discussion that lead to the decisions being made > > happened before I was involved. My understanding is that the idea was > > that the dynamic linker would be responsible for mapping everything in > > dynamic applications other than itself but other than consistency I > > don't know why. I guess it defers more decision making to userspace but > > I'm having a hard time thinking of sensible cases where one might wish > > to make a decision other than enabling PROT_BTI. > > My understanding was this had been agreed with the toolchain folk a > while back -- anything static loaded by the kernel (i.e. a static > executable or the dynamic linker) would get GP set. In other cases the > linker will mess with the permissions on the pages anyhow, and needs to > be aware of BTI in order to do the right thing, so it was better to > leave it to userspace consistently (e.g. as that had the least risk of > subtle changes in behaviour leading to ABI difficulties). So this means that the interpreter will have to mprotect(PROT_BTI) the text section of the primary executable. For subsequent libraries, it calls mmap() explicitly anyway but not for the main executable (IIUC). > > I'd be perfectly happy to drop the check if that makes more sense to > > people, otherwise I can send a patch adding a comment explaining the > > situation. > > I think it would be best to document the current behaviour, as it's a > simple ABI that we can guarantee, and the dynamic linker will have to be > aware of BTI in order to do the right thing anyhow. That's a valid point. If we have an old dynamic linker and the kernel enabled BTI automatically for the main executable, could things go wrong (e.g. does the PLT need to be BTI-aware)? -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel