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 1C31EC388F9 for ; Tue, 27 Oct 2020 14:17:06 +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 CDC4D206F7 for ; Tue, 27 Oct 2020 14:17:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eJgvNRha" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDC4D206F7 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=sXIqyxLvsVybgtBSnOlI1obXwWvdUWXb9YQyK9CG+vU=; b=eJgvNRhaAnrls9jFrITvuDrvI NLSVnhUHbUbHnLDjGu34effBVbHq0pNxN0sD2zgNtuTcldaOkNrFnheBdGQFiBfFtyykswHExorT7 quX+JH+43OvDNHBRokb21MlHcHwuuYTzN8hatSHtn8fPvjpRi6m9qmQwIaMItFcH9gxYl+UMtZQOA d0vbH9C2d/1+wO814Z+qtCuqR2581EMXYTUwc004OnTbkjsiQH/GqxU31PGUiNrNog+Y61Pkji9OG y1FKAz6+Q63p8ME8pQkgiQTbUUmUGQGu5zcL72oitoytQ6e06kEqpG0d7X5PhtbujPZJD3S2BT1Sp CGQtsJRXg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXPl6-0003Dh-12; Tue, 27 Oct 2020 14:15:32 +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 1kXPl3-0003D0-6w for linux-arm-kernel@lists.infradead.org; Tue, 27 Oct 2020 14:15:30 +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 D8E1E150C; Tue, 27 Oct 2020 07:15:27 -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 545943F719; Tue, 27 Oct 2020 07:15:26 -0700 (PDT) Date: Tue, 27 Oct 2020 14:15:22 +0000 From: Dave Martin To: Jeremy Linton Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201027141522.GD27285@arm.com> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201026162410.GB27285@arm.com> <20201026165755.GV3819@arm.com> <20201026175230.GC27285@arm.com> <45c64b49-a38b-4b0c-d9cf-6c586dacbcc9@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <45c64b49-a38b-4b0c-d9cf-6c586dacbcc9@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-20201027_101529_357261_634ABA55 X-CRM114-Status: GOOD ( 30.44 ) 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 , Szabolcs Nagy , 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-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 05:39:42PM -0500, Jeremy Linton via Libc-alpha wrote: > 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. That works, though I'm not so keen on teating PROT_BTI as a special case, since the problem is likely to recur when other weird per-arch flags get added... I also wonder whether we actually care whether the pages are marked executable or not here; probably the flags can just be independent. This rather depends on whether the how the architecture treats the BTI (a.k.a GP) pagetable bit for non-executable pages. I have a feeling we already allow PROT_BTI && !PROT_EXEC through anyway. What about a generic-ish set/clear interface that still works by just adding a couple of PROT_ flags: switch (flags & (PROT_SET | PROT_CLEAR)) { case PROT_SET: prot |= flags; break; case PROT_CLEAR: prot &= ~flags; break; case 0: prot = flags; break; default: return -EINVAL; } This can't atomically set some flags while clearing some others, but for simple stuff it seems sufficient and shouldn't be too invasive on the kernel side. We will still have to take the mm lock when doing a SET or CLEAR, but not for the non-set/clear case. Anyway, libc could now do: mprotect(addr, len, PROT_SET | PROT_BTI); with much the same effect as your PROT_BTI_IF_X. JITting or breakpoint setting code that wants to change the permissions temporarily, without needing to know whether PROT_BTI is set, say: mprotect(addr, len, PROT_SET | PROT_WRITE); *addr = BKPT_INSN; mprotect(addr, len, PROT_CLEAR | PROT_WRITE); Thoughts? I won't claim this doesn't still have some limitations... Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel