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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 793B7C433DB for ; Mon, 8 Feb 2021 18:50:28 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 392BD64E74 for ; Mon, 8 Feb 2021 18:50:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 392BD64E74 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=h4fx9LENh98EFuqXReh8f721VMH8v+xBCs6ZJO4rws0=; b=w3uelqnpjEKl7bnuIiGGoYtWm PRP04LrKP38n50yeICjxTPg+7sMZ6nzeKi4w0YqlbtRKlp6rBnlcAQmJg8jKSxQAmgCMaT62+tTJ7 UVSPZZEeCfU0kriu9ZpOiG6Qycs9T+oYvJE8IbONhQ9jLoDhX+wzKablDtMH+Hjot6PSEjqvtyyDX NXDOM7V1IsEpEl2MyYd2awrupmkJeWwWm2+RfOm3sVRquP8ax3xuT+hdN37KLN1J9wuyxmxDabDmT 4t4SKcCNvvrkY5CJt5ibB09/5I+YO3dV1eR1JPCeF8qdiA8sL6zBYiZfrq+wA2gc7gOytwJxpVTSP DOsJl/rCQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Bax-0000rV-T8; Mon, 08 Feb 2021 18:49:11 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Bau-0000qn-Vc for linux-arm-kernel@lists.infradead.org; Mon, 08 Feb 2021 18:49:10 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 885A364E84; Mon, 8 Feb 2021 18:49:05 +0000 (UTC) Date: Mon, 8 Feb 2021 18:49:03 +0000 From: Catalin Marinas To: Dave Martin Subject: Re: [PATCH] arm64: bti: Set PROT_BTI on all BTI executables mapped by the kernel Message-ID: <20210208184902.GC12694@gaia> References: <20210205173837.39315-1-broonie@kernel.org> <20210205175128.GB12697@gaia> <20210208124451.GB25618@willie-the-truck> <20210208141329.GC8542@arm.com> <20210208164744.GA16506@arm.com> <20210208174028.GG21837@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210208174028.GG21837@arm.com> 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-20210208_134909_124918_E3340B04 X-CRM114-Status: GOOD ( 29.31 ) 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: Mark Rutland , libc-alpha@sourceware.org, Kees Cook , Szabolcs Nagy , Jeremy Linton , Mark Brown , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 08, 2021 at 05:40:29PM +0000, Dave P Martin wrote: > On Mon, Feb 08, 2021 at 04:47:45PM +0000, Szabolcs Nagy via Libc-alpha wrote: > > The 02/08/2021 14:13, Szabolcs Nagy via Libc-alpha wrote: > > > The 02/08/2021 12:44, Will Deacon wrote: > > > > I'd like an Ack from Szabolcs before we queue this. > > > > > > i'm ok with this in principle, but i will rerun > > > the glibc tests over night to be sure. > > > > > > the patch applied cleanly on top of arm64 for-next/core > > > > but it does not work as i expected: > > > > executables that do not have the bti property note > > set seems to get bti guarded by the kernel. > > > > at least i see crash in _start when the dynamic > > linker (which has bti marking) transfers control > > to it and the start code has no bti c. > > > > (according to strace the dynamic linker did not > > remap/mprotect the main exe with bti so i assume > > this is the kernel's doing) > > > > can somebody verify that the notes are checked > > on the executable too and not just on ld.so? Thanks Szabolcs for testing. > Reviewed-by bites the dust... > > Aha, looking at the ELF code in the kernel, it looks like some extra > refactoring is needed. > > We do the heavy lifting only for the image containing the userspace > entry point -- i.e., ld.so in the dynamically linked case. This > includes the ELF property handling. When ld.so is present, the main > executable is just data so we map it in but don't do a whole lot else > with it: > > static int load_elf_binary(struct linux_binprm *bprm) > { > /* ... */ > > retval = parse_elf_properties(interpreter ?: bprm->file, > elf_property_phdata, &arch_state); > > The way I originally integrated this therefore just tracks the BTI-ness > (and/or equivalently how to mutate PROT_EXEC) once. Looks like we need > to do that independently for ld.so and for the executable instead. > > We could simplify things by treating it as an error if the executable > and ld.so have different BTI properties, but that seems a bit of an own > goal, since it breaks foreseeable backwards compatibility / hybrid use > cases. Ah, I haven't thought of these cases either. In theory, if the dynamic loader hasn't been compiled with -mbranch-protection=bti, it does not mean it won't be able to use PROT_BTI on the mapped executable/libraries. The same goes for BTI-compiled loader with a non-BTI executable, it should be allowed. So I think decoupling the two makes sense but the patch is no longer as simple as the ELF loader now needs to parse the main executable. If that's doable and the code looks sane, I'd go with it. Otherwise, we scrap the idea of the kernel setting PROT_BTI on the main executable. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel