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=-8.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 28D73C4363A for ; Thu, 22 Oct 2020 09:31:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCB8224196 for ; Thu, 22 Oct 2020 09:31:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2895986AbgJVJbN (ORCPT ); Thu, 22 Oct 2020 05:31:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:53288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2509974AbgJVJbN (ORCPT ); Thu, 22 Oct 2020 05:31:13 -0400 Received: from gaia (unknown [95.145.162.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F1281222E9; Thu, 22 Oct 2020 09:31:07 +0000 (UTC) Date: Thu, 22 Oct 2020 10:31:05 +0100 From: Catalin Marinas To: Lennart Poettering Cc: Szabolcs Nagy , Topi Miettinen , Florian Weimer , Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Will Deacon , "linux-kernel@vger.kernel.org" , Mark Brown , libc-alpha@sourceware.org, Dave Martin , "linux-arm-kernel@lists.infradead.org" Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201022093104.GB1229@gaia> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022071812.GA324655@gardel-login> <87sga6snjn.fsf@oldenburg2.str.redhat.com> <511318fd-efde-f2fc-9159-9d16ac8d33a7@gmail.com> <20201022082912.GQ3819@arm.com> <20201022083823.GA324825@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201022083823.GA324825@gardel-login> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote: > On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.nagy@arm.com) wrote: > > > > The dynamic loader has to process the LOAD segments to get to the ELF > > > > note that says to enable BTI. Maybe we could do a first pass and load > > > > only the segments that cover notes. But that requires lots of changes > > > > to generic code in the loader. > > > > > > What if the loader always enabled BTI for PROT_EXEC pages, but then when > > > discovering that this was a mistake, mprotect() the pages without BTI? Then > > > both BTI and MDWX would work and the penalty of not getting MDWX would fall > > > to non-BTI programs. What's the expected proportion of BTI enabled code vs. > > > disabled in the future, is it perhaps expected that a distro would enable > > > the flag globally so eventually only a few legacy programs might be > > > unprotected? > > > > i thought mprotect(PROT_EXEC) would get filtered > > with or without bti, is that not the case? > > We can adjust the filter in systemd to match any combination of > flags to allow and to deny. Yes but Szabolcs' point to Topi was that if we can adjust the filters to allow mprotect(PROT_EXEC), why not allow mprotect(PROT_EXEC|PROT_BTI) instead? Anyway, I see the MDWX and BTI as complementary policies so ideally we shouldn't have to choose between one or the other. If we allow mprotect(PROT_EXEC), that would override MDWX and also disable BTI. IIUC, the problem is with the main executable which is mapped by the kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but does not have the original file descriptor to be able to remap. Its only choice is mprotect() and this fails because of the MDWX policy. Not sure whether the kernel has the right information but could it map the main executable with PROT_BTI if the corresponding PT_GNU_PROPERTY is found? The current ABI states it only sets PROT_BTI for the interpreter who'd be responsible for setting the PROT_BTI on the main executable. I can't tell whether it would break anything but it's worth a try: diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 4784011cecac..0a08fb9133e8 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -730,14 +730,6 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void) int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state, bool has_interp, bool is_interp) { - /* - * For dynamically linked executables the interpreter is - * responsible for setting PROT_BTI on everything except - * itself. - */ - if (is_interp != has_interp) - return prot; - if (!(state->flags & ARM64_ELF_BTI)) return prot; -- Catalin 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=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 56573C4363A for ; Thu, 22 Oct 2020 09:32:40 +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 D0C4121481 for ; Thu, 22 Oct 2020 09:32:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yG9f/tnW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0C4121481 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=u8ezXjpGXtb6YX0zfwAL1hOh/1hOsxXfwrZBzl3oh2E=; b=yG9f/tnWyHf7XLea4IWg36LmL QcqG17RwOVpJb8yxqTe7gLw0oGrAU79hMVCJZSTMDLCXd1yCwoWTQbK3WaRzA8mJHl8rsEJzkqfOJ VIp24uCPlmWyOa769YVBcAB/wjRtCzKg/RGUSCHL4QqWiWGAtZCqSDKT9+7Gf26hVphrfDf1Nc18O XMGTSLNzWBz03b9eloFEmHm6kHIAYpNEoUr67nSJAgfY/1uQI303mN1EdVH9P6/MHR7zghMRtmajG ilV3RQxdPMp7scIBzynAmzpRipizU9+aNrt/nQ/Yb5R6bdqRPBYX8zT5S0MpQQQfEkCXT6fDNvZFz ygGaesBKA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVWwE-0004oZ-Mv; Thu, 22 Oct 2020 09:31:14 +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 1kVWwB-0004o7-45 for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 09:31:11 +0000 Received: from gaia (unknown [95.145.162.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F1281222E9; Thu, 22 Oct 2020 09:31:07 +0000 (UTC) Date: Thu, 22 Oct 2020 10:31:05 +0100 From: Catalin Marinas To: Lennart Poettering Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201022093104.GB1229@gaia> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022071812.GA324655@gardel-login> <87sga6snjn.fsf@oldenburg2.str.redhat.com> <511318fd-efde-f2fc-9159-9d16ac8d33a7@gmail.com> <20201022082912.GQ3819@arm.com> <20201022083823.GA324825@gardel-login> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201022083823.GA324825@gardel-login> 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-20201022_053111_328420_D734D91F X-CRM114-Status: GOOD ( 28.24 ) 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: Florian Weimer , Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Szabolcs Nagy , Will Deacon , "linux-kernel@vger.kernel.org" , Mark Brown , Topi Miettinen , libc-alpha@sourceware.org, Dave Martin , "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 Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote: > On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.nagy@arm.com) wrote: > > > > The dynamic loader has to process the LOAD segments to get to the ELF > > > > note that says to enable BTI. Maybe we could do a first pass and load > > > > only the segments that cover notes. But that requires lots of changes > > > > to generic code in the loader. > > > > > > What if the loader always enabled BTI for PROT_EXEC pages, but then when > > > discovering that this was a mistake, mprotect() the pages without BTI? Then > > > both BTI and MDWX would work and the penalty of not getting MDWX would fall > > > to non-BTI programs. What's the expected proportion of BTI enabled code vs. > > > disabled in the future, is it perhaps expected that a distro would enable > > > the flag globally so eventually only a few legacy programs might be > > > unprotected? > > > > i thought mprotect(PROT_EXEC) would get filtered > > with or without bti, is that not the case? > > We can adjust the filter in systemd to match any combination of > flags to allow and to deny. Yes but Szabolcs' point to Topi was that if we can adjust the filters to allow mprotect(PROT_EXEC), why not allow mprotect(PROT_EXEC|PROT_BTI) instead? Anyway, I see the MDWX and BTI as complementary policies so ideally we shouldn't have to choose between one or the other. If we allow mprotect(PROT_EXEC), that would override MDWX and also disable BTI. IIUC, the problem is with the main executable which is mapped by the kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but does not have the original file descriptor to be able to remap. Its only choice is mprotect() and this fails because of the MDWX policy. Not sure whether the kernel has the right information but could it map the main executable with PROT_BTI if the corresponding PT_GNU_PROPERTY is found? The current ABI states it only sets PROT_BTI for the interpreter who'd be responsible for setting the PROT_BTI on the main executable. I can't tell whether it would break anything but it's worth a try: diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 4784011cecac..0a08fb9133e8 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -730,14 +730,6 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void) int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state, bool has_interp, bool is_interp) { - /* - * For dynamically linked executables the interpreter is - * responsible for setting PROT_BTI on everything except - * itself. - */ - if (is_interp != has_interp) - return prot; - if (!(state->flags & ARM64_ELF_BTI)) return prot; -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel