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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 AAAA7C4363A for ; Thu, 22 Oct 2020 07:26:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 740A8222E9 for ; Thu, 22 Oct 2020 07:26:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2508531AbgJVH0z (ORCPT ); Thu, 22 Oct 2020 03:26:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2508514AbgJVH0x (ORCPT ); Thu, 22 Oct 2020 03:26:53 -0400 X-Greylist: delayed 513 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 22 Oct 2020 00:26:52 PDT Received: from gardel.0pointer.net (gardel.0pointer.net [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD677C0613CE for ; Thu, 22 Oct 2020 00:26:52 -0700 (PDT) Received: from gardel-login.0pointer.net (gardel.0pointer.net [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by gardel.0pointer.net (Postfix) with ESMTP id AC041E8080C; Thu, 22 Oct 2020 09:18:14 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 20608160834; Thu, 22 Oct 2020 09:18:12 +0200 (CEST) Date: Thu, 22 Oct 2020 09:18:12 +0200 From: Lennart Poettering To: Jeremy Linton Cc: "linux-arm-kernel@lists.infradead.org" , libc-alpha@sourceware.org, systemd-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Mark Rutland , Kees Cook , Szabolcs Nagy , Catalin Marinas , Will Deacon , Mark Brown , Dave Martin Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201022071812.GA324655@gardel-login> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.linton@arm.com) wrote: > Hi, > > There is a problem with glibc+systemd on BTI enabled systems. Systemd > has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny > PROT_EXEC changes. Glibc enables BTI only on segments which are marked as > being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is > caught by the seccomp filter, resulting in service failures. > > So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. > This is obviously not desirable. > > Various changes have been suggested, replacing the mprotect with mmap calls > having PROT_BTI set on the original mapping, re-mmapping the segments, > implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, > and various modification to seccomp to allow particular mprotect cases to > bypass the filters. In each case there seems to be an undesirable attribute > to the solution. > > So, whats the best solution? Did you see Topi's comments on the systemd issue? https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 I think I agree with this: it's a bit weird to alter the bits after the fact. Can't glibc set up everything right from the begining? That would keep both concepts working. Lennart -- Lennart Poettering, Berlin