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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D8E49C4363A for ; Thu, 22 Oct 2020 10:04:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B5B92417D for ; Thu, 22 Oct 2020 10:04:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="denJkyKo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2896290AbgJVKEV (ORCPT ); Thu, 22 Oct 2020 06:04:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2896273AbgJVKEU (ORCPT ); Thu, 22 Oct 2020 06:04:20 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DD4BC0613CE for ; Thu, 22 Oct 2020 03:04:20 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id d24so1505356lfa.8 for ; Thu, 22 Oct 2020 03:04:20 -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=v+g60jSFAWmJk25t84LrgkacnZZF5EGyn0T0qZYVJPQ=; b=denJkyKo92QmJssuyfNHfRh0bkOUOm5JqGz3HF1V9AggK73d8uBn1SVUc6JwVPJT3t CZZH2hDr8ZvCnvN5OuDbmntXCPNXzvk9S9X0CIc0r3jl31ctji8I/Jnzw+Cjgombxodf pJ+LcpOpCw+4LSzfK7fIJbztKe2RblaEqbo6uG6Qil0PDVeAIo2/vyKdke/9/hOHob2R zdikt4Q9Rxzuw+JOmRY1Wvj//l5kpKiNlCk/sDoUMLkG+J2OSKzstDfkBdYN9xoiAxI8 9j6/5ywhVoesc97aCeT5ocNG+WPTaZmjOxHhy0+4XEMwne8jJ7X6KQUlwHe0d4/R8uz8 vBlg== 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=v+g60jSFAWmJk25t84LrgkacnZZF5EGyn0T0qZYVJPQ=; b=IVRFpd9KE8yCrnEVfKA7LFOm7A1EKfySfeCCs+C5djW1esNsHTGaVvmsw0bNNFQ4hO L/Lp0UdAzuYwMh3oC0iRjc72GLOtG6Quy7qk4VcjVJyveqMn9gYnRoSnDEmPG5n41LB1 fFlwl4hz+pP/qJhSer1u1zONYv8IR0krbjDS//PxWnu4OUXPhjxqPclbZZsSr3WQauJe odE4v19uBfJSDk2tlDS40yYA/kDfWlKIAYI+ymNGAzQyQFBFrsYDtQkEuWafSBrVsUcm 3xfY5R3PuFCzxTdrBsEzLYr4klH60ehYjQzhOVcf0FhjWr8cKvZcgKNfhvktwp3QByBH Gx2A== X-Gm-Message-State: AOAM531fW6WnNh8WxMIB5Mowp+UlebIzoBua+Kngp8Qgq7yP4/UhHta8 9ICOj4Zxahg0Ch6GMSGXi/g= X-Google-Smtp-Source: ABdhPJwH9XOdDe0YlZMRGx22HEpQlzpQeIUZpjxkbSUK3SepOq2QRD5zb2keQbFEDVMtjNYwhkZhhw== X-Received: by 2002:a19:434f:: with SMTP id m15mr528494lfj.601.1603361058694; Thu, 22 Oct 2020 03:04:18 -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 m4sm227110ljg.137.2020.10.22.03.04.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2020 03:04:18 -0700 (PDT) Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Szabolcs Nagy Cc: Florian Weimer , Lennart Poettering , 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> <511318fd-efde-f2fc-9159-9d16ac8d33a7@gmail.com> <20201022082912.GQ3819@arm.com> From: Topi Miettinen Message-ID: <55b44a39-ab19-363e-3703-9bf4e7d75f68@gmail.com> Date: Thu, 22 Oct 2020 13:03:59 +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: <20201022082912.GQ3819@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 On 22.10.2020 11.29, Szabolcs Nagy wrote: > The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: >> On 22.10.2020 10.54, Florian Weimer wrote: >>> * Lennart Poettering: >>>> 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? > > i thought mprotect(PROT_EXEC) would get filtered > with or without bti, is that not the case? It would be filtered, but the idea is that with modern binaries this would not happen since the pages would be mapped with mmap(,, PROT_EXEC | PROT_BTI,,) which is OK for purposes MDWX. The loader would have to use mprotect(PROT_EXEC) to get rid of PROT_BTI only for the legacy binaries. -Topi 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=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 3EC4FC5517A for ; Thu, 22 Oct 2020 10:05:50 +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 AFFAA24196 for ; Thu, 22 Oct 2020 10:05:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1AgY83nT"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="denJkyKo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFFAA24196 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=K1exwtQXQWj9fHyFDPaWjzGF32y+eHJrVnuvL0Ki2wE=; b=1AgY83nT7Um/hanFg+ctI2Ls5 vUGyTXF+khnq2001eOVR4KtJ4JRm9SyPtH9hQLqtGQFsK+1aid83kykMHbT3Wt9srHYrNd8CxDHtY UReBAOHixHssis4L8CF+mlrsJI4n0fQXug3fZRcFrXieSUWcHf3+0EmUk6a6iqQbUIQ5xl/mKIbdR NMo79bJdXUpHp6IPiY4sndfYjp+bUQpzmDK7g5Ue5MMTsZFxE9i3N0YnMPhv6kYmYLqhvST5ckjgM ys16ersV6EJftdOVH+W+dYl5nsjaSglQdvnYI2sWmWqJPrsa93via66ugE2V7aZ4aPRw0Mlwrt0F3 BKUm3C4fA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVXSQ-0000pe-Gn; Thu, 22 Oct 2020 10:04:30 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVXSN-0000n5-Gl for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 10:04:28 +0000 Received: by mail-lf1-x142.google.com with SMTP id r127so1485781lff.12 for ; Thu, 22 Oct 2020 03:04:19 -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=v+g60jSFAWmJk25t84LrgkacnZZF5EGyn0T0qZYVJPQ=; b=denJkyKo92QmJssuyfNHfRh0bkOUOm5JqGz3HF1V9AggK73d8uBn1SVUc6JwVPJT3t CZZH2hDr8ZvCnvN5OuDbmntXCPNXzvk9S9X0CIc0r3jl31ctji8I/Jnzw+Cjgombxodf pJ+LcpOpCw+4LSzfK7fIJbztKe2RblaEqbo6uG6Qil0PDVeAIo2/vyKdke/9/hOHob2R zdikt4Q9Rxzuw+JOmRY1Wvj//l5kpKiNlCk/sDoUMLkG+J2OSKzstDfkBdYN9xoiAxI8 9j6/5ywhVoesc97aCeT5ocNG+WPTaZmjOxHhy0+4XEMwne8jJ7X6KQUlwHe0d4/R8uz8 vBlg== 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=v+g60jSFAWmJk25t84LrgkacnZZF5EGyn0T0qZYVJPQ=; b=WvKhVUo11fB1cWOlqMKYGojnUsgcHXekISAiJyqzKVw6xCk+3dRj9KCv4BHz/XYq0m MBHc7BCDjRHcM3WhwygnRceT1vJkdpSEu0espwSa721FUAoPCCqLl2OsTAfW2taMHQNb uibxOe08YDClYKYjcRzme+AmFLSWZkIMzoXoaFyfAOWJqcgRKi4ucgKZu5S3b86r5Iwr gPloF91olQYVAXLXtjJ6VA3Bl+mNqkvjdt2E97746Owv/9Js8l2JJKMG4h8JRXEEHdTg fVdQC3jzYF6EFB+tlUZWjCuH6xBpc1Jhdnigo/ca3Avb4E8MLyskQXY/pJvSvV8mINYV HZxw== X-Gm-Message-State: AOAM531rv2HAOQolKuYWp2iAtTUeFM7Fuvnn4Jik0+XU9trB8XJvXF0t rRZSZuP2n0LmYrcUUU9a/XMEAInoLm4= X-Google-Smtp-Source: ABdhPJwH9XOdDe0YlZMRGx22HEpQlzpQeIUZpjxkbSUK3SepOq2QRD5zb2keQbFEDVMtjNYwhkZhhw== X-Received: by 2002:a19:434f:: with SMTP id m15mr528494lfj.601.1603361058694; Thu, 22 Oct 2020 03:04:18 -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 m4sm227110ljg.137.2020.10.22.03.04.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2020 03:04:18 -0700 (PDT) Subject: Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Szabolcs Nagy References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022071812.GA324655@gardel-login> <87sga6snjn.fsf@oldenburg2.str.redhat.com> <511318fd-efde-f2fc-9159-9d16ac8d33a7@gmail.com> <20201022082912.GQ3819@arm.com> From: Topi Miettinen Message-ID: <55b44a39-ab19-363e-3703-9bf4e7d75f68@gmail.com> Date: Thu, 22 Oct 2020 13:03:59 +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: <20201022082912.GQ3819@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_060427_578657_1904BA8C X-CRM114-Status: GOOD ( 19.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: Florian Weimer , Mark Rutland , systemd-devel@lists.freedesktop.org, Kees Cook , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Mark Brown , Lennart Poettering , 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 11.29, Szabolcs Nagy wrote: > The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: >> On 22.10.2020 10.54, Florian Weimer wrote: >>> * Lennart Poettering: >>>> 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? > > i thought mprotect(PROT_EXEC) would get filtered > with or without bti, is that not the case? It would be filtered, but the idea is that with modern binaries this would not happen since the pages would be mapped with mmap(,, PROT_EXEC | PROT_BTI,,) which is OK for purposes MDWX. The loader would have to use mprotect(PROT_EXEC) to get rid of PROT_BTI only for the legacy binaries. -Topi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel