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.3 required=3.0 tests=BAYES_00, 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 D4A7AC4363A for ; Mon, 26 Oct 2020 17:52:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 956502072D for ; Mon, 26 Oct 2020 17:52:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1788591AbgJZRwk (ORCPT ); Mon, 26 Oct 2020 13:52:40 -0400 Received: from foss.arm.com ([217.140.110.172]:46326 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1788579AbgJZRwh (ORCPT ); Mon, 26 Oct 2020 13:52:37 -0400 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 43CD7139F; Mon, 26 Oct 2020 10:52:36 -0700 (PDT) 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 B2B113F66E; Mon, 26 Oct 2020 10:52:34 -0700 (PDT) Date: Mon, 26 Oct 2020 17:52:31 +0000 From: Dave Martin To: Szabolcs Nagy Cc: Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Jeremy Linton , Mark Brown , toiwoton@gmail.com, libc-alpha@sourceware.org, "linux-arm-kernel@lists.infradead.org" Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201026175230.GC27285@arm.com> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <20201026165755.GV3819@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201026165755.GV3819@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 26, 2020 at 04:57:55PM +0000, Szabolcs Nagy via Libc-alpha wrote: > The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote: > > Unrolling this discussion a bit, this problem comes from a few sources: > > > > 1) systemd is trying to implement a policy that doesn't fit SECCOMP > > syscall filtering very well. > > > > 2) The program is trying to do something not expressible through the > > syscall interface: really the intent is to set PROT_BTI on the page, > > with no intent to set PROT_EXEC on any page that didn't already have it > > set. > > > > > > This limitation of mprotect() was known when I originally added PROT_BTI, > > but at that time we weren't aware of a clear use case that would fail. > > > > > > Would it now help to add something like: > > > > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags) > > { > > int ret = -EINVAL; > > mmap_write_lock(current->mm); > > if (all vmas in [addr .. addr + len) have > > their mprotect flags set to old_flags) { > > > > ret = mprotect(addr, len, new_flags); > > } > > > > mmap_write_unlock(current->mm); > > return ret; > > } > > if more prot flags are introduced then the exact > match for old_flags may be restrictive and currently > there is no way to query these flags to figure out > how to toggle one prot flag in a future proof way, > so i don't think this solves the issue completely. Ack -- I illustrated this model because it makes the seccomp filter's job easy, but it does have limitations. > i think we might need a new api, given that aarch64 > now has PROT_BTI and PROT_MTE while existing code > expects RWX only, but i don't know what api is best. An alternative option would be a call that sets / clears chosen flags and leaves others unchanged. The trouble with that is that the MDWX policy then becomes hard to implement again. But policies might be best set via another route, such as a prctl, rather than being implemented completely in a seccomp filter. Cheers ---Dave 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.3 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 D4AECC4363A for ; Mon, 26 Oct 2020 17:54:03 +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 7604520791 for ; Mon, 26 Oct 2020 17:54:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HIU0NGJa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7604520791 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=sLDzIe2W/IR0jjNOYBF3113i+LPJu0vrVxC20qxeTLA=; b=HIU0NGJay66rCbnvLDXTjOYIp XCQflp0WVaTS3vNk0q3VrfIbqegAIOKUwbNgceKBY73fxtw3JPjiQzbvF3MC+wQ+vnBCap2pMYEkQ Lp6f9Rv7bGG/H54ZJiFyVCYZKF/8w8NDiqpapjgOH3bWihK7dMe4KuAE4Z/HSNvSWfaVbpyREtzT/ t11s/116xepzBMQUnf41mbZbOWFjDZxHztYY0VGJOKMg4DqjQ2VYvYl3jnSrfYzRXSYqZ6Q7UJlON zHOme0QXFlRB5X4ZgeBdIQA7HwWodQu4oxvr6yukq5UN/fYDB6tyHxtIqP+HixHRqr9o5ikp6kdJZ l5AaUP45A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kX6fg-0007Db-7S; Mon, 26 Oct 2020 17:52:40 +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 1kX6fe-0007Cq-4I for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 17:52:39 +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 43CD7139F; Mon, 26 Oct 2020 10:52:36 -0700 (PDT) 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 B2B113F66E; Mon, 26 Oct 2020 10:52:34 -0700 (PDT) Date: Mon, 26 Oct 2020 17:52:31 +0000 From: Dave Martin To: Szabolcs Nagy Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201026175230.GC27285@arm.com> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <20201026165755.GV3819@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201026165755.GV3819@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-20201026_135238_282518_E1AD1088 X-CRM114-Status: GOOD ( 26.17 ) 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 , systemd-devel@lists.freedesktop.org, Kees Cook , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Jeremy Linton , Mark Brown , toiwoton@gmail.com, libc-alpha@sourceware.org, "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, Oct 26, 2020 at 04:57:55PM +0000, Szabolcs Nagy via Libc-alpha wrote: > The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote: > > Unrolling this discussion a bit, this problem comes from a few sources: > > > > 1) systemd is trying to implement a policy that doesn't fit SECCOMP > > syscall filtering very well. > > > > 2) The program is trying to do something not expressible through the > > syscall interface: really the intent is to set PROT_BTI on the page, > > with no intent to set PROT_EXEC on any page that didn't already have it > > set. > > > > > > This limitation of mprotect() was known when I originally added PROT_BTI, > > but at that time we weren't aware of a clear use case that would fail. > > > > > > Would it now help to add something like: > > > > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags) > > { > > int ret = -EINVAL; > > mmap_write_lock(current->mm); > > if (all vmas in [addr .. addr + len) have > > their mprotect flags set to old_flags) { > > > > ret = mprotect(addr, len, new_flags); > > } > > > > mmap_write_unlock(current->mm); > > return ret; > > } > > if more prot flags are introduced then the exact > match for old_flags may be restrictive and currently > there is no way to query these flags to figure out > how to toggle one prot flag in a future proof way, > so i don't think this solves the issue completely. Ack -- I illustrated this model because it makes the seccomp filter's job easy, but it does have limitations. > i think we might need a new api, given that aarch64 > now has PROT_BTI and PROT_MTE while existing code > expects RWX only, but i don't know what api is best. An alternative option would be a call that sets / clears chosen flags and leaves others unchanged. The trouble with that is that the MDWX policy then becomes hard to implement again. But policies might be best set via another route, such as a prctl, rather than being implemented completely in a seccomp filter. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel