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 47EF4C433E0 for ; Mon, 8 Feb 2021 17:41:59 +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 DFF2B64D9F for ; Mon, 8 Feb 2021 17:41:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFF2B64D9F 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=V06SKvGHjDE4WUFWnEngejxpne6szunDBSpcwkkNzpc=; b=b7PSKzRxJsTHSK0BmX8VQxmXw t6gETAgf6we9uNfxdFyz3tu5qOsZX78u+ABVzQTwBur9PwdjaoJYLI4CK19kK+cRTPNn2WB0p9gjd mzwRiGF9v91Kuk4BKxBgS75SAMQ93ATwgLoDXTWMnpRYCQJaAzRenFYxSeMlj+DtUlvcA8/sBJImD wpHk6LSmo5GycJCZPkTRk1CAG40KRY6r+VnJtu3V/h6L0h6bB2L36YCB8I04tQ+SIxULRLjHt3kJG 5Y81Cqgpiup0uvTaGS8lb9KIsceuVajx14QR7t6fCP0YSWG0QkFh5aP9tr/lASua52YgyK+C5dQiF VqDrbbWKw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9AWu-0003Xz-9Q; Mon, 08 Feb 2021 17:40:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9AWr-0003XS-Dn for linux-arm-kernel@lists.infradead.org; Mon, 08 Feb 2021 17:40:54 +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 16CFA1042; Mon, 8 Feb 2021 09:40:52 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CCB5E3F719; Mon, 8 Feb 2021 09:40:50 -0800 (PST) Date: Mon, 8 Feb 2021 17:40:29 +0000 From: Dave Martin To: Szabolcs Nagy Subject: Re: [PATCH] arm64: bti: Set PROT_BTI on all BTI executables mapped by the kernel Message-ID: <20210208174028.GG21837@arm.com> References: <20210205173837.39315-1-broonie@kernel.org> <20210205175128.GB12697@gaia> <20210208124451.GB25618@willie-the-truck> <20210208141329.GC8542@arm.com> <20210208164744.GA16506@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210208164744.GA16506@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210208_124053_981159_34D8812A X-CRM114-Status: GOOD ( 24.52 ) 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 , Catalin Marinas , 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 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? 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. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel