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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9193AC77B75 for ; Mon, 8 May 2023 14:10:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E74CC6B0074; Mon, 8 May 2023 10:10:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E257B6B0078; Mon, 8 May 2023 10:10:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D145A6B007D; Mon, 8 May 2023 10:10:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C11B36B0074 for ; Mon, 8 May 2023 10:10:12 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 96C6EC01C0 for ; Mon, 8 May 2023 14:10:12 +0000 (UTC) X-FDA: 80767272264.19.506BEDD Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id B00BB140003 for ; Mon, 8 May 2023 14:10:10 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683555010; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Sos8ApbdEqrZmsw40O2qsoz8GX2VyeAx71c3jTyYgbM=; b=nFCMgU4Ld0k0LsQPLRNBqK3PAlKiMuojTJGx/CBab6CAanIcA6S1hqMHFf/NR2fJKbIptf USVtBn5/V98tCQspGWmI50EcXWpyTldHPEWfk9Zqa9ZutqKFiuW2vM2vJ3gGfGDicMo4De KcEpBLtDz9yUbYxfqdWM6zzV/3Qjx7g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683555010; a=rsa-sha256; cv=none; b=kjnFHYurmSoSLPS89xOAJUEF31Ei3foflVUssm06wH+qxOFoQShVYgqNCP89hevRf6JoVx PuHvRT3UZJKeLQZS9ur/ULJhMJmf0uSG1PLKV89pBD2eJy9Af/yT97OM6uv0yMWHCwT4Pd fE0m9TNgIbHKv/MRyzKvn+TdDQJQSW4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2D2EA63E55; Mon, 8 May 2023 14:10:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE777C433D2; Mon, 8 May 2023 14:10:05 +0000 (UTC) Date: Mon, 8 May 2023 15:10:02 +0100 From: Catalin Marinas To: Florent Revest Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, anshuman.khandual@arm.com, joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org, david@redhat.com, izbyshev@ispras.ru, nd@arm.com, broonie@kernel.org, szabolcs.nagy@arm.com, toiwoton@gmail.com, lennart@poettering.net Subject: Re: [PATCH 0/4] MDWE without inheritance Message-ID: References: <20230504170942.822147-1-revest@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: B00BB140003 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 95bzo74xu4x3xxa97dxn485xqoxg7twg X-HE-Tag: 1683555010-762684 X-HE-Meta: U2FsdGVkX1/SuGnE0ex0ZOCEia/IlyNIHUt4gvwVUjJWZkI/UTllviVkY428L/vqXydQC7u086wb9C6uK0Jw5b4yLuy5vfOPnMEoeHe0MWdZgHh4aUYAZ4a3/icFR+TWfvIoJZtphc+iCrcbrlZbemrPEkSt2849KikRr80LQgXulYBbZXVvvM7p95D8hcwcQFkkzU2u4ImkTpI20nzF52TWv/aaa0TopsiictXyYoNAvFWGXhu9hly6YUb3ROSKQorT0WhiXNeG8mMcSXYUsd4YQeKp5No0pEZOu8WczjRFQRy6GaFN2IaOBnWYqGu7nHaGxlvoTy0DWqOd1fJUvheI4JfMuFAOqzmIvLEhsPS4zG/oai4OGidmU9cjzdg1mMmOxjQ6j+00xmGBsJTgNtxI7i93RTh8/r+/r8FwmWuNGIQR/nsYOQOV17bLlvH0Ze5WfO1/0r+hgbkpJJs1SIrj/Ypxi8DFn3nDU1RqWrWJYnZFduEOran6dkfsv+srmpZHTZCjtlL1oc3frCH5oSboT6i7AqfM82SkS9S1dtJ5fKhzciqgzpIObDXAEYMrV2qJOvWVYtmHTGWpJVBnkt8v2+Dh7hIc4nwyR1+NXwnnwMV40KyXx7yJoadHB1aam+ErVxxHNHr4lhDx1PGMXjjpGWDvsnzvxJYKFmW5M0SOp5SC+jYoSCQyjNslg0NplHyh7KygNDJpuhtLCL99PPejmeta8vpIEmcz8P9gZeagjWHIq4s28g1HKcnNBGJ7aSZPfgJgIuYfJPkICgs8KDemgspljVZt4X4evF1ngt/sU3AgfUwnp65CPYWMg3Y6A36gyHAYtIvZNnV209VBDfyxdrh/kdMwjHMDtkbySWfd/bqAYKzjSqWWtjyI5C+4+VMZOjsg3Kjkm6F7xEJXqzKkLLenYlvfgCYsdYbWcyaoitJMe6WfpU1q8qn8ne72tUyG5V3oOcbhuWzvJYa zkqoyEhv D/PMxL3lIKkJy0zY9JTSbG33ReXSYgi/0KEcS9A/gBijrCGMkXoq3YUhCvIpooTf89zbwKwJR+ekZlKAVj0kHEIf4bzYXVcFAvnsrXYfKM3XuzIO7tLpv3nhgiCLJ7rmPuO9lDiJ6bkPoR8hzS6n/L7NU8QcSRIM6pb7goQtQOttixV1y7pShXZiVMMZBA2H1KtIkeNmu2NaVqsmOZsOas7sfo4shyQ/cF3cNaAnmhXqkKtrGnb/Zvu9zUeCmbgq3Ulsgk50xvPZlrhifn43iQVTQaHmT7uyPYA0QhnQc/QAYztFlZXXXcERQlxLNlEcsroW3ItHoa3caBHVuWBgc2e+4gIxxE5M7o+k56MU22m9HbiEwXmUK+auxuqImmoRHt1Xn71AV/+/ZkOBcFXX3urmn+BCYNr/UT45BGPzaJNvgD91Jy/d53aGWdhF/lsfn8fKf X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 08, 2023 at 02:12:21PM +0200, Florent Revest wrote: > On Mon, May 8, 2023 at 3:29 AM Peter Xu wrote: > > On Fri, May 05, 2023 at 06:42:08PM +0200, Florent Revest wrote: > > > On Thu, May 4, 2023 at 10:06 PM Peter Xu wrote: > > > > And, what's the difference of this comparing to disabling MDWE after being > > > > enabled (which seems to be forbidden for now, but it seems fork() can play > > > > a similar role of disabling it)? > > > > > > That would be functionally somewhat similar, yes. I think it mostly > > > comes down to ease of adoption. I imagine that users who would opt > > > into NO_INHERIT are those who are interested in MDWE for the binary > > > they are writing but aren't 100% confident in what subprocesses they > > > will run and so they don't have to think about disabling it after > > > every fork. > > > > Okay, that makes sense to me. Thanks. > > > > Since the original MDWE was for systemd, I'm wondering what will happen if > > some program like what you said is invoked by systemd and with MDWE enabled > > already. > > Good question I think JITs work around this by creating two separate mappings of the same pages, one RX and the other RW (rather than toggling the permission with mprotect()). I had the impression Chromium can use memfd to do something similar but I never checked. > > Currently in your patch IIUC MDWE_NO_INHERIT will fail directly on MDWE > > enabled process, > > Yes, I tried to stay close to the spirit of the existing logic (which > doesn't allow any sort of privilege gains) but this is not > particularly a requirement on our side so I'm quite flexible here. I think we should keep the original behaviour of systemd here, otherwise they won't transition to the new interface and keep using the SECCOMP BPF approach (which, in addition, prevents glibc from setting PROT_BTI on an already executable mapping). To me MDWE is not about preventing JITs but rather ensuring buggy programs don't end up with WX mappings. We ended up this way because of the SECCOMP BPF limitations (just guessing, I haven't been involved in its design). With a no-inherit MDWE, one can introduce an additional policy for systemd. It would be a sysadmin decision which one to enable and maybe current (inherit) MDWE will disappear in time. x86 has protection keys and arm64 will soon have permission overlays that allow user-space to toggle between RX and RW (Joey is looking at the arm64 support). I'm not sure how we'll end up implemented this on arm64 (and haven't looked at x86) but I have a suspicion MDWE will get in the way as the base page table permission will probably need PROT_WRITE|PROT_EXEC. -- Catalin