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=-10.1 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 060D3C4363A for ; Thu, 22 Oct 2020 08:19: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 66DE921481 for ; Thu, 22 Oct 2020 08:19:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GZ4Whet+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lo1gjkqP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66DE921481 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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=dFfMhv8vUBbx7cV4TK79INsd+FurFO84uZ3UqG7hJzc=; b=GZ4Whet+q3zu1UOCD21UVmat5 8XGfM7u8faRG5Y4361sEwRLNtBXbes9EUZHaxpamSYh977roUkCe/GrDjg8p219wjISsigB62BzfH um6txpqmZbhBjG/oykYyIyv0IcdcYD9QQz8KnEAEzdoEIQROhkjQjFhjgAVH6teG9GJVRy11P+Nds TAVtQjgGeovULtsUczYC3PIIwWiND4K43mxch+8EssTWuD6TftN4aq856dEiTvrWELTZ2hcWZWwIq Zxif3kct2H5S+pOUwnV5u19qiTb4SpGlNoPwr9K/psftGiOcwKaIpVz1zUpON4oS61K1DPL2yVKBb dKJkl2usw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVVn6-00014m-7T; Thu, 22 Oct 2020 08:17:44 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVVn2-00013o-QU for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 08:17:41 +0000 Received: by mail-lf1-x133.google.com with SMTP id 184so1140729lfd.6 for ; Thu, 22 Oct 2020 01:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8HYVfJFH+cmeus6VJeMKUXXnaDsK6MzsFkED7ZSnMuM=; b=lo1gjkqPQq/3i6U4FJ0Ro4myZDcbR+atFTQwMG5g8ALJulSqy0fO4Z+1pIH0jHVGL4 Ql/X1AJpnZs6z1fTSn6a5qgG0nNMxOV6MzXR/EEolZmLZa1NoBOTeh/0kiuD9YoEa4Vv hmk7io9opZfIapHfa8wlfROEIqpr6qwwjJNx0qtTeITK8kDg2ixjuZJ+vpQ5oKgpfyNR 94ss/pu34Pvn+rHzaERpFpUp86NeswuianA34kcK+0/34JVyzKmw8oVIFCpS8Mb/yHEn Tnzdjb7I0l8m9wehOU5U1Vfe3peSgeUOOxEarCoovs9N0kh+YkL6iI2N5h5AdFpoo88O VwOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8HYVfJFH+cmeus6VJeMKUXXnaDsK6MzsFkED7ZSnMuM=; b=gG6Id62NYB8BVgTxdVyV123OzU5Ua4n0dhf7o2J6x56HwA6Q+MKZhQKfr0RWWTqEb/ LMCpx8nHnnC2zfSSf1JF22BQ/tgrQpHEgAyH6IcWDpxYYEwjgfzVQEt0TVv0ycwmPmnc ARKW4QVDqzOsof61AkDGLr6hPKdR/ocnkfkhViuiAp6FW6yGpXrfpWN/gxbELkNiKFfs c3Fvlp+I/1ZcvQIM+jVliTRW4POliXctUDJ7lKYe7+LI0uscJG8qmH2wNhpePNWUDzTe CJFuFeMj34SE5g/+WkiGfn32vegCyN5BZH8+lymEUEHyB2sPziKAX6hsR86HNK3AHVdJ cqhQ== X-Gm-Message-State: AOAM531wBztYrM/2J68EJ7fLF851d27PhtqbHNCyjMES5mhOM1OeN7jO 273I/8Hj0BACqZ8wrBqn6HHD8UdkDps= X-Google-Smtp-Source: ABdhPJwWZL3I0YCdmzYXRbsvsREOh3P1rTMxFf9qvQvDcdbABeRyQT7+/UgfusPG41cJSHDVowERSQ== X-Received: by 2002:ac2:521a:: with SMTP id a26mr422161lfl.10.1603354657804; Thu, 22 Oct 2020 01:17:37 -0700 (PDT) Received: from [192.168.1.112] (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id r5sm182350ljm.77.2020.10.22.01.17.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2020 01:17:37 -0700 (PDT) Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Florian Weimer , Lennart Poettering References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022071812.GA324655@gardel-login> <87sga6snjn.fsf@oldenburg2.str.redhat.com> From: Topi Miettinen Message-ID: <511318fd-efde-f2fc-9159-9d16ac8d33a7@gmail.com> Date: Thu, 22 Oct 2020 11:17:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87sga6snjn.fsf@oldenburg2.str.redhat.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_041740_881947_98670A32 X-CRM114-Status: GOOD ( 21.38 ) 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 , libc-alpha@sourceware.org, Dave Martin , "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 On 22.10.2020 10.54, Florian Weimer wrote: > * Lennart Poettering: > >> 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. > > 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? -Topi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel