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=-7.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 CA0F9C4363A for ; Mon, 26 Oct 2020 22:39:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7ABDE20878 for ; Mon, 26 Oct 2020 22:39:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394607AbgJZWjt (ORCPT ); Mon, 26 Oct 2020 18:39:49 -0400 Received: from foss.arm.com ([217.140.110.172]:54016 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730294AbgJZWjt (ORCPT ); Mon, 26 Oct 2020 18:39:49 -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 4EB0C30E; Mon, 26 Oct 2020 15:39:43 -0700 (PDT) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD7DE3F68F; Mon, 26 Oct 2020 15:39:42 -0700 (PDT) Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Dave Martin , Szabolcs Nagy Cc: Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Mark Brown , toiwoton@gmail.com, libc-alpha@sourceware.org, "linux-arm-kernel@lists.infradead.org" References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <20201026165755.GV3819@arm.com> <20201026175230.GC27285@arm.com> From: Jeremy Linton Message-ID: <45c64b49-a38b-4b0c-d9cf-6c586dacbcc9@arm.com> Date: Mon, 26 Oct 2020 17:39:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201026175230.GC27285@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/26/20 12:52 PM, Dave Martin wrote: > 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. I tend to favor a set/clear API, but that could also just be done by creating a new PROT_BTI_IF_X which enables BTI for areas already set to _EXEC. That goes right by the seccomp filters too, and actually is closer to what glibc wants to do anyway. > > 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=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 85A3CC4363A for ; Mon, 26 Oct 2020 22:41:39 +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 2E76520878 for ; Mon, 26 Oct 2020 22:41: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="HlB8xAVU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E76520878 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=C1Zji1eBGjuy5YQW9ePSdB6lAs7+eVmt/6S2sIg/VPM=; b=HlB8xAVUWLUoZgodWQOpLLSBt JqkfhfETqkOKgrD/gr/cfFqbXcj+IPJY5bCm0E5kxxXqomLXVgYDPOZxwUGX0Z7HGp+a/TQlWhj0j YrHZ0iEOoVNJwrlCqxoLA5NoGLyhbnAP3zt991QPsGiRVFPmICZyCu4bgRBb1CReF2N9YC5vzzwXr 7b4Hnx5StO6Z3xnnIMNHVlSoS/bUz2KiQaWQ+sbhB88xJGu7RzqM2oKvkT/zrUpXOFVHzus0jBsk2 0dwtTHrXEeLA61eePqTTHODmxyRXzccA/vQnCWJwgUxYyaDyZNGrmu/qHmzywgu5qwk2V6yqtKku3 jiHiufWHw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXB9i-00024h-A1; Mon, 26 Oct 2020 22:39:58 +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 1kXB9f-00023d-6H for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 22:39:56 +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 4EB0C30E; Mon, 26 Oct 2020 15:39:43 -0700 (PDT) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD7DE3F68F; Mon, 26 Oct 2020 15:39:42 -0700 (PDT) Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Dave Martin , Szabolcs Nagy References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <20201026165755.GV3819@arm.com> <20201026175230.GC27285@arm.com> From: Jeremy Linton Message-ID: <45c64b49-a38b-4b0c-d9cf-6c586dacbcc9@arm.com> Date: Mon, 26 Oct 2020 17:39:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201026175230.GC27285@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_183955_304375_6F33CDDA X-CRM114-Status: GOOD ( 26.30 ) 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" , Mark Brown , toiwoton@gmail.com, libc-alpha@sourceware.org, "linux-arm-kernel@lists.infradead.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 10/26/20 12:52 PM, Dave Martin wrote: > 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. I tend to favor a set/clear API, but that could also just be done by creating a new PROT_BTI_IF_X which enables BTI for areas already set to _EXEC. That goes right by the seccomp filters too, and actually is closer to what glibc wants to do anyway. > > 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