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=-6.7 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 A352AC433FE for ; Thu, 3 Dec 2020 17:31:41 +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 2DE64207B0 for ; Thu, 3 Dec 2020 17:31:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DE64207B0 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=/A2eYN7/bAiqI3YD9AUEbZb6VfRlWPA985lvt8YQX9g=; b=VqN5zXzBRXmBS8AF99kKlGN0T THzXjhEXgCU96vYuYVjUJCDZt24Lugx4YgQTgjaaSTOiDKl8KeAVv6jpTfEPAy5GzF3G9ZEAoXBNJ IFtPTBU0nTXichDS10iRXERkDP5x0bgTfDfLwR6bt5eq5lNmn/TJg0l4ObemSBdTS420IA9erJo5Q WY2uvNeeIHJ+Et39ZjJVhgi9dA4oe2RW7TJ+4Oz/y0kBtlEwYvTjXrsoLbthnqsYp9kUqozDrjm5d 5oEx8LrdqB9Z+F7Ft02Sd5cUC45dC7HaKxLGx4AQAEgBrqs5diw3mzTLEhH3SZ5+nXxb+p/ROia0p ZYzur5UPA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kksQq-0005LY-CB; Thu, 03 Dec 2020 17:30:16 +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 1kksQn-0005LD-3m for linux-arm-kernel@lists.infradead.org; Thu, 03 Dec 2020 17:30:14 +0000 Date: Thu, 3 Dec 2020 17:30:06 +0000 From: Catalin Marinas To: Szabolcs Nagy Subject: Re: [PATCH v2 0/6] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831] Message-ID: <20201203173006.GH2830@gaia> References: 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-20201203_123013_304078_D1C5FC35 X-CRM114-Status: GOOD ( 22.17 ) 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 , libc-alpha@sourceware.org, kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org, Jeremy Linton , Mark Brown , Topi Miettinen , Will Deacon , 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 Hi Szabolcs, On Fri, Nov 27, 2020 at 01:19:16PM +0000, Szabolcs Nagy wrote: > This is v2 of > https://sourceware.org/pipermail/libc-alpha/2020-November/119305.html > > To enable BTI support, re-mmap executable segments instead of > mprotecting them in case mprotect is seccomp filtered. > > I would like linux to change to map the main exe with PROT_BTI when > that is marked as BTI compatible. From the linux side i heard the > following concerns about this: > - it's an ABI change so requires some ABI bump. (this is fine with > me, i think glibc does not care about backward compat as nothing > can reasonably rely on the current behaviour, but if we have a > new bit in auxv or similar then we can save one mprotect call.) I'm not concerned about the ABI change but there are workarounds like a new auxv bit. > - in case we discover compatibility issues with user binaries it's > better if userspace can easily disable BTI (e.g. removing the > mprotect based on some env var, but if kernel adds PROT_BTI and > mprotect is filtered then we have no reliable way to remove that > from executables. this problem already exists for static linked > exes, although admittedly those are less of a compat concern.) This is our main concern. For static binaries, the linker could detect, in theory, potential issues when linking and not set the corresponding ELF information. At runtime, a dynamic linker could detect issues and avoid enabling BTI. In both cases, it's a (static or dynamic) linker decision that belongs in user-space. > - ideally PROT_BTI would be added via a new syscall that does not > interfere with PROT_EXEC filtering. (this does not conflict with > the current patches: even with a new syscall we need a fallback.) This can be discussed as a long term solution. > - solve it in systemd (e.g. turn off the filter, use better filter): > i would prefer not to have aarch64 (or BTI) specific policy in > user code. and there was no satisfying way to do this portably. I agree. I think the best for now (as a back-portable glibc fix) is to ignore the mprotect(PROT_EXEC|PROT_BTI) error that the dynamic loader gets. BTI will be disabled if MDWX is enabled. In the meantime, we should start (continue) looking at a solution that works for both systemd and the kernel and be generic enough for other architectures. The stateless nature of the current SECCOMP approach is not suitable for this W^X policy. Kees had some suggestions here but the thread seems to have died: https://lore.kernel.org/kernel-hardening/202010221256.A4F95FD11@keescook/ -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel