Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp340992pxu; Fri, 23 Oct 2020 02:04:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/iqvrIRMQXWq/zxZhcZfs1Yzo0Z6h98ZMOYGBEBEdnGVgf7eFa2z8mXwy+6H+34dJ6JNM X-Received: by 2002:a17:906:4816:: with SMTP id w22mr1065645ejq.458.1603443880409; Fri, 23 Oct 2020 02:04:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603443880; cv=none; d=google.com; s=arc-20160816; b=iuuuZ6+TIo0prgJKS75QbOTCJ+LcY1PS0HAdltwtNhr+WmhXWooiRuJKSZy1ymug6b PTrS5mdJ+rV10s6JNHp9xKgP/GfEwwShSj8hcuiQhY6ItImv43KyRiTw5RAbGoTi+FkW DVv31cS7hNjqr0qPtH8C0a7TH0x6M7bGwfPkRE2YBcj9ef/pxwNYaZTfFdEugxepNdjb jK5CRGWjfXRCmUTUsb48+1eb04MmhPR1e0pEY0iWecPYWKcBq4R9sJ815+QtHlcQTaAz Hr1EoZke6F3O5nVkhsJZwpdHAW9mhf6miBwtC1wRbhLdKfUW13UAQQo+5ApMNaKQPrNK ctwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=A6iS59kBIqVYuKrAMktxw8WaO+qGi6Njc8u2l0qqIQY=; b=kKt50JftFteDlXKgJJiiMdTgrzlRAH/mrnV1x5FKHTA6fv70bZRzD80lwPjI6GM+mJ kNp/sDNo0SS7XV4bQ9BeO4TrbrWZpITIeHvEOrROYWg0/XIDFuItPQf0wSNSYRzLGdeI vY8URZFr2kK0g9ZirHhpCGAV11LOMOqy0rdCjNjMKR6SQt2nvOuO5erH6grcYWG582r1 gogu/AlrKe5uSI6lk0wYa6CaelPo4jh2pn6ZRdIE8/i0kqNVraDr+bhge8t0r0eP/4tP gM7rBemCKRxLSoY7e4UlxHNJTMem5xGssM5x6Ly2glaZD+Q+ZY97aEQ+sIvX6UpkwEjZ R+CA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l90si365275edl.249.2020.10.23.02.04.18; Fri, 23 Oct 2020 02:04:40 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S461043AbgJWJCi (ORCPT + 99 others); Fri, 23 Oct 2020 05:02:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:47494 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S460918AbgJWJCi (ORCPT ); Fri, 23 Oct 2020 05:02:38 -0400 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 5F24921D43; Fri, 23 Oct 2020 09:02:35 +0000 (UTC) Date: Fri, 23 Oct 2020 10:02:32 +0100 From: Catalin Marinas To: Kees Cook Cc: Topi Miettinen , 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: <20201023090232.GA25736@gaia> References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022075447.GO3819@arm.com> <78464155-f459-773f-d0ee-c5bdbeb39e5d@gmail.com> <202010221256.A4F95FD11@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202010221256.A4F95FD11@keescook> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Catalin