Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5843983pxu; Thu, 22 Oct 2020 12:29:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWng0yH7hGGCGeZoP42Sz41P/jJgFj/+kIXg4dmsipXqURRJwRxZrYKoyA7YRa8xWXAqx7 X-Received: by 2002:a05:6402:1bcc:: with SMTP id ch12mr3712615edb.339.1603394940259; Thu, 22 Oct 2020 12:29:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603394940; cv=none; d=google.com; s=arc-20160816; b=XQJMB9YOkliQhSOJwnNn0+OhINsIldrOX5G5WG0F0sBc75X/TRxj68qmiIE1qob0mI 0x0+pGC8/mLZBeX+KhnzA7ZcLPnMFmWVhuapfTjvKHCKVPV8bTzeAARDELVzXxY1YC7d 3p6Y6mfw4GRk6xRd6/oYq95VQCw79/J25BauWFph61Ohm0lOQa1/rEOeLRPcgwLt8jPK eqixL03NmLA7PrQOW3+lnOQQC95Ae+Lt4xmiL01IQE9va6cJoNk7e3eYF6FEFzLl7Boy fT1KK0XI0mgShhFFQAwEGb9XCGCdx8QY3nkj6d4WS2tR5YLHFsDmUiXbvz0JcYx4k1hr cojQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=LytsYpgQbIMoWASGiX+s5kJie60h8ouZtjTv4Y6yd3g=; b=Eptgutdh93oequtW7f/QkOr61Z96oL6tW7AWONvzIyXqVSlb9xJAsQDVjWC2r8q78Y RLIha0dDWpZudeuGELbYGmHQrc1MSkew07W+xxKKUcRMM4dAWaSG0X055fRTzvnaVKEm WZYCFNTOFhqrfaJmzyuiW9xLteNkXO3h+5S0pOdGk7DImLHcSz0Y0sbWgvkh75/H5xKU AQVGhcXWimC6zzCp5koeDtudUAN/dhBzZ+mmBWeH9DK4b13TP1Ubh7Z1Lhoyo8d8eAhu QikSmk7D7qpLfp81dt8GsfP6fA3cXFPcQV7xE7DH90fQha+WKOf783Qlt5ZRTuACrU9X jVwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w1si966074edf.49.2020.10.22.12.28.38; Thu, 22 Oct 2020 12:29:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2510003AbgJVJbN (ORCPT + 99 others); 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