Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5432210pxu; Thu, 22 Oct 2020 02:02:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxE33P+ZCb3noLCqMdZL7hoEW899EKEf1oZVoHpsqF+fDkbtpHw1OpFRFlgUaDSHcNUzKJl X-Received: by 2002:a17:906:aecf:: with SMTP id me15mr1334438ejb.423.1603357368881; Thu, 22 Oct 2020 02:02:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603357368; cv=none; d=google.com; s=arc-20160816; b=Ki2rh6PDimsIpndQrh1EfqQVZQFGqQSh9C21h+u46SwDWJQj3DHmms3PdzOQhfu7v1 DFrwdCGVgBvfGjOpjk6Iu/mUuEIc97B6UfwB/6paTWytRniqssfRJNKrwF01ld8jduqe Cbx2t0Pk+PA6USv4+AwhFQa5V+GMvO6Mq4gQiYU57yYzkiaVIg67ImGzLl3g6Dm8/Pll GyKxOtH9z4oey4qTjLHDN+zA+7Lufuc6CKu8+Iel/ETk05PTiLeEh5DdE6ZvXjB8RDg5 J1mHWxCoUX8oDARtl6OUY9nJsk2Ut5TWkzrL4LsBLGoAq+Ar1bI96Ro69/G/4ZeGHdxP o/eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=8HYVfJFH+cmeus6VJeMKUXXnaDsK6MzsFkED7ZSnMuM=; b=S9qfgz/7PVwqCAiZHhp4T5KH8Kecgph45miOWHdfqYBPNykvHu9G03GjVXRgcx1EL3 bV9g8d6xXhEa+YKUw/NiivOM+SfSbGUURWucYvJ42kTg7BL92IQumQqT/A9wLv3pkFB1 x1+C4kMMnCQgV1v98vCXVq3qbW1Xr6Abi0Azk802qpebRC/clpLzgKaU81XYIM5b9Q1T RIfU02t1bQSpcjqa6JzBoWGvLErlXh+N422lTBzf7F7GcuaZzTJBVbgQcA7EumLfGIUT ylka9O+14QwAuoySITgPIyLsk9zBFDIcPhmWIXkC+2820MQWMm47UezPkETOYJYJpa40 5XdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lo1gjkqP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l23si552971ejb.743.2020.10.22.02.02.26; Thu, 22 Oct 2020 02:02:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lo1gjkqP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2894791AbgJVIRk (ORCPT + 99 others); Thu, 22 Oct 2020 04:17:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2894673AbgJVIRj (ORCPT ); Thu, 22 Oct 2020 04:17:39 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5402AC0613CE for ; Thu, 22 Oct 2020 01:17:39 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b1so1125678lfp.11 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=YWyaxaNal6fyrWpTnwpkdkkWp15mES3UkbEHgXxRFGIZ3t2ckix3mtItxHwLYma/w7 P6KnYZkO0kVni6dSfixy9ExIB0M8i2J+LIBsAVNISJhETPguUeD/ydUeXWqXr2WBUeUY SQ7eaqq8d79S4sHjAbaBhFxA0QAP+sprqCVSgN/57u85Qycs1FiA0AfmIDq2awIBcw9H g5hbYze83eevQex9kRTWIf1HdW+Fykc72+F4ytkQ6apj4UTAhkWTaexVwm7BR9jmXCW9 F2lWeuNDQ9+87qiMa1gj2s+VlmrU1iBYRdRcMUVIY92cQt+KzmnepyscAEMFMcCpzCse 2avA== X-Gm-Message-State: AOAM532+igoIMq3G8caCe3ep6l0+M5k/juSjSkRoELM6F0C3NrzdeLiT pWseIJB8Yn5uJFoog9HK5Ec= 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 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" 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-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 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