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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 A7EA1C4363A for ; Mon, 26 Oct 2020 17:28:12 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id D87432223C for ; Mon, 26 Oct 2020 17:28:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D87432223C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-20275-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 4093 invoked by uid 550); 26 Oct 2020 17:28:00 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 11550 invoked from network); 26 Oct 2020 14:53:05 -0000 Date: Mon, 26 Oct 2020 14:52:46 +0000 From: Catalin Marinas To: Topi Miettinen Cc: Kees Cook , Szabolcs Nagy , Jeremy Linton , "linux-arm-kernel@lists.infradead.org" , libc-alpha@sourceware.org, systemd-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Mark Rutland , Mark Brown , Dave Martin , Will Deacon , Salvatore Mesoraca , kernel-hardening@lists.openwall.com, linux-hardening@vger.kernel.org Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201026145245.GD3117@gaia> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022075447.GO3819@arm.com> <78464155-f459-773f-d0ee-c5bdbeb39e5d@gmail.com> <202010221256.A4F95FD11@keescook> <20201023090232.GA25736@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote: > On 23.10.2020 12.02, Catalin Marinas wrote: > > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote: > > > Regardless, it makes sense to me to have the kernel load the executable > > > itself with BTI enabled by default. I prefer gaining Catalin's suggested > > > patch[2]. :) > > [...] > > > [2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/ > > > > I think I first heard the idea at Mark R ;). > > > > It still needs glibc changes to avoid the mprotect(), or at least ignore > > the error. Since this is an ABI change and we don't know which kernels > > would have it backported, maybe better to still issue the mprotect() but > > ignore the failure. > > What about kernel adding an auxiliary vector as a flag to indicate that BTI > is supported and recommended by the kernel? Then dynamic loader could use > that to detect that a) the main executable is BTI protected and there's no > need to mprotect() it and b) PROT_BTI flag should be added to all PROT_EXEC > pages. We could add a bit to AT_FLAGS, it's always been 0 for Linux. > In absence of the vector, the dynamic loader might choose to skip doing > PROT_BTI at all (since the main executable isn't protected anyway either, or > maybe even the kernel is up-to-date but it knows that it's not recommended > for some reason, or maybe the kernel is so ancient that it doesn't know > about BTI). Optionally it could still read the flag from ELF later (for > compatibility with old kernels) and then do the mprotect() dance, which may > trip seccomp filters, possibly fatally. I think the safest is for the dynamic loader to issue an mprotect() and ignore the EPERM error. Not all user deployments have this seccomp filter, so they can still benefit, and user can't tell whether the kernel change has been backported. Now, if the dynamic loader silently ignores the mprotect() failure on the main executable, is there much value in exposing a flag in the aux vectors? It saves a few (one?) mprotect() calls but I don't think it matters much. Anyway, I don't mind the flag. The only potential risk is if the dynamic loader decides not to turn PROT_BTI one because of some mix and match of objects but AFAIK BTI allows interworking. -- Catalin 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 C0E14C2D0A3 for ; Mon, 26 Oct 2020 14:54:42 +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 8488020773 for ; Mon, 26 Oct 2020 14:54:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iWU4Qj7i" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8488020773 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=nbcjZON63if0cin66ivccYSH93jjWgu6Dp6UIEVJE6s=; b=iWU4Qj7iBKke4OidhTg486Xd2 QQrSb+nDIlAD59azEQmMposduqzXle7sKxDl8pLWXFyCXKQZ/xjkQkplvuyKceeuDxFGLrDilZ+35 RG3sZ4/3M/vH2/9YkejkjjMZ5Lnvzgvyf78xgEqIdVu8q+91SSKBy83L2LO8nlvr/QZef7Yo3jV2M F1US2tKAwA1gd/n4nAgI7IdeMYS1drLC1sV4BHBWiwN8eph8nthGiu2NARR+/cto/pjN1Eaeu0XF6 qGgf+l5OSIRX539aGt746QHg7jZv6bxL4uSMv4/X3BLWbHdZSPIMk3w/qbcYbcq4W+WzRfUXV6S7c CAIBvQe5A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kX3rk-00067E-Ne; Mon, 26 Oct 2020 14:52:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kX3rh-00066O-Uy for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 14:52:54 +0000 Received: from gaia (unknown [95.145.162.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AADC720773; Mon, 26 Oct 2020 14:52:49 +0000 (UTC) Date: Mon, 26 Oct 2020 14:52:46 +0000 From: Catalin Marinas To: Topi Miettinen Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures Message-ID: <20201026145245.GD3117@gaia> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022075447.GO3819@arm.com> <78464155-f459-773f-d0ee-c5bdbeb39e5d@gmail.com> <202010221256.A4F95FD11@keescook> <20201023090232.GA25736@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_105254_078785_D7F0B414 X-CRM114-Status: GOOD ( 25.92 ) 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 , Salvatore Mesoraca , systemd-devel@lists.freedesktop.org, Kees Cook , kernel-hardening@lists.openwall.com, Szabolcs Nagy , Will Deacon , "linux-kernel@vger.kernel.org" , Jeremy Linton , Mark Brown , linux-hardening@vger.kernel.org, libc-alpha@sourceware.org, Dave Martin , "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 Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote: > On 23.10.2020 12.02, Catalin Marinas wrote: > > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote: > > > Regardless, it makes sense to me to have the kernel load the executable > > > itself with BTI enabled by default. I prefer gaining Catalin's suggested > > > patch[2]. :) > > [...] > > > [2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/ > > > > I think I first heard the idea at Mark R ;). > > > > It still needs glibc changes to avoid the mprotect(), or at least ignore > > the error. Since this is an ABI change and we don't know which kernels > > would have it backported, maybe better to still issue the mprotect() but > > ignore the failure. > > What about kernel adding an auxiliary vector as a flag to indicate that BTI > is supported and recommended by the kernel? Then dynamic loader could use > that to detect that a) the main executable is BTI protected and there's no > need to mprotect() it and b) PROT_BTI flag should be added to all PROT_EXEC > pages. We could add a bit to AT_FLAGS, it's always been 0 for Linux. > In absence of the vector, the dynamic loader might choose to skip doing > PROT_BTI at all (since the main executable isn't protected anyway either, or > maybe even the kernel is up-to-date but it knows that it's not recommended > for some reason, or maybe the kernel is so ancient that it doesn't know > about BTI). Optionally it could still read the flag from ELF later (for > compatibility with old kernels) and then do the mprotect() dance, which may > trip seccomp filters, possibly fatally. I think the safest is for the dynamic loader to issue an mprotect() and ignore the EPERM error. Not all user deployments have this seccomp filter, so they can still benefit, and user can't tell whether the kernel change has been backported. Now, if the dynamic loader silently ignores the mprotect() failure on the main executable, is there much value in exposing a flag in the aux vectors? It saves a few (one?) mprotect() calls but I don't think it matters much. Anyway, I don't mind the flag. The only potential risk is if the dynamic loader decides not to turn PROT_BTI one because of some mix and match of objects but AFAIK BTI allows interworking. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel