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 471B7C05027 for ; Mon, 23 Jan 2023 16:04:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D5E96B0072; Mon, 23 Jan 2023 11:04:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 986296B0073; Mon, 23 Jan 2023 11:04:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84CC16B0074; Mon, 23 Jan 2023 11:04:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6F2586B0072 for ; Mon, 23 Jan 2023 11:04:32 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3C1E8C0989 for ; Mon, 23 Jan 2023 16:04:32 +0000 (UTC) X-FDA: 80386536384.27.B28DB4C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id DD59710001C for ; Mon, 23 Jan 2023 16:04:28 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf14.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674489869; 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: in-reply-to:in-reply-to:references:references; bh=ru0ELEMkjpR6UncGV/m9e5Axp68F78zcicKvewKhbOM=; b=BPz1PxYs3HmNZKllYLg3W/4JHvpqbtT2Z819Jw3cq2CJwuZh+/XStl/yjMlQEJTvhV4Frg PWwV3LmuWDTURIqVz6QZEaxbtkMR0RFN5PYCq5s3pCsOvC9ijv8jy0YitCNy5lQG8iKTdm kp5D8wULMDudXcIZdbv+cZ+tWQLETTM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf14.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674489869; a=rsa-sha256; cv=none; b=uQ++O/UErOJ9LVLgsjjU1dw0YInk5tPIZiqiNi5uUleEAezkwuuD7OW5lW2ZEtkq7Nja39 paq1DDQ+0lvnAYe6vo/cJG2IoHxiAHxQ4TVRPSzX2eTA1E8c30r2cTME95ICAK3YCvNYMN XJrgurRo1LCXvz9GYvQRDzwYDCnGTko= 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 ams.source.kernel.org (Postfix) with ESMTPS id 2F92CB80DEF; Mon, 23 Jan 2023 16:04:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CABFEC433D2; Mon, 23 Jan 2023 16:04:22 +0000 (UTC) Date: Mon, 23 Jan 2023 16:04:19 +0000 From: Catalin Marinas To: David Hildenbrand Cc: Joey Gouly , Andrew Morton , Lennart Poettering , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Alexander Viro , Kees Cook , Szabolcs Nagy , Mark Brown , Jeremy Linton , Topi Miettinen , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-abi-devel@lists.sourceforge.net, nd@arm.com, shuah@kernel.org Subject: Re: [PATCH v2 1/2] mm: Implement memory-deny-write-execute as a prctl Message-ID: References: <20230119160344.54358-1-joey.gouly@arm.com> <20230119160344.54358-2-joey.gouly@arm.com> <4a1faf67-178e-c9ba-0db1-cf90408b0d7d@redhat.com> <8b4e31cf-de20-703c-4b53-ad86d4282a37@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b4e31cf-de20-703c-4b53-ad86d4282a37@redhat.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DD59710001C X-Rspam-User: X-Stat-Signature: j7th5171shtj1amei7od7h4f9815f6bw X-HE-Tag: 1674489868-494055 X-HE-Meta: U2FsdGVkX194fW0el+4GwnRHFbQcOmEjePEQr6Qe6GXaRvu6TeIYGu8fU4R4cFaLfsCcdILF32h81apTituhuOJLPvMHeAokCj950cU07x7AiAZz5HKzIx91peMnKQuOBzDNpniOCnooDkFGpWpZEWEqvaWCg6NNk86yDUaA9nQxf7zLxnNoeUNzx4VRbopjq1CZUGjCshUfbPer3PHYpcmw3gnfrKJH27DOQjtznaMcZPNzDid1ETHhaxbVPomEguU9RQfsYarZx4sTXK3kRFyUOk5q4XeBJy0+XI8UkgW9MoedDaorxtxmS5RfwnYwtbTgJkTRKQrjjCjVU/kNpsjzCkHLPO7MnhpIvhv8ZsGvU2e5HJnf97I8YHHadYR/40FqGdNqaqUOyySKQ11joNSdzQ26bNeE4nqDvutnXzxMvORL+k4Nq0ng0Xx7tkW39tuvKjN/RuIWzUo1m1X34Z3pFQSZq8KYT+E+NRtLLHtdmG6e0C45lX6107LtXHW/tH6Cca8sNYY2DIBTVnCWxtxpn2y7g7sdDnZhnAsIAwUGTtzD6JWoIi8UCOXkTuDMju364IL5v26sBwWfpu9Hk7kUkqcb/cUqxVOhqWDK/g8dEwk30/nL+GM5wtqZT/7YKO490Ov2moW1cLn0HkdzGn0DAcT0WU8GasabVbI0OHxIF0KOZgoRkHB8gssAc5LC6bpm2qS6smRItLXrfc/Duzh2izQuUhb0obvOHeSsYOaDZSE/n+lmdnWbRurw1IyzvpB1whj0qUk7RICDLKiU3FiVYRRTJDt5auzSnHTh2k36A1EZ1RFNQP0TgZAzhbARf+A3PjTzMQLE4K+rGHPRljcsRdhbGq0OGSFLKCyVOcVJuLK23Bt6reT3hkwcGCkSf5IiGXTZMzdHrDn9FjOYnnAflSAeQ0MXFFF6/GWtZMKyRy3r8swvJRGy/dUKnOrqEvMHxrjmP6la0cv5Cv8 xGCuX4Xd jhGtkVX1xhsa2phfj5IPWA7tXcSBykO18JxJSOZ65Qn2nWbLIZF2HfAI4pfDZ3rYMenAhEPiXZfNBQb+VX0f1+eJm5VAKUZw0kM5uPV1NpFefz/5UBAVZ25hdPHitygTQkZFezcdWHUOTO8cqQZvaRG3aQ1RwiG+WC3yDcOTjKsX4tfAVhYCOW6mdEgH+BIrZkG6KDTKWsCmNTCBMoPZeaLSxpLOaJ1SjWVuHs8XGNaTnEFU7PjBOz6R/fGs4bxJIq0hXxUIPH89FE4rw332ZS5U2Ounuheo/Spz2v+oPR9V3mZeIH/wKIhmQkVlD30was3IyULK9FNLfPllI9fjycF6rM5ToB1MLFQ84gUzXbd49vNeZ+im5SGkfJ19q3S4DNnWXxdQD68plewiqqD6PQfarIzRwSdgcBlFWOKYJarNXoG1MCLXf6HAeqQ== 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, Jan 23, 2023 at 01:53:46PM +0100, David Hildenbrand wrote: > On 23.01.23 13:19, Catalin Marinas wrote: > > On Mon, Jan 23, 2023 at 12:45:50PM +0100, David Hildenbrand wrote: > > > On 19.01.23 17:03, Joey Gouly wrote: > > > > diff --git a/include/linux/mman.h b/include/linux/mman.h > > > > index 58b3abd457a3..cee1e4b566d8 100644 > > > > --- a/include/linux/mman.h > > > > +++ b/include/linux/mman.h > > > > @@ -156,4 +156,38 @@ calc_vm_flag_bits(unsigned long flags) > > > > } > > > > unsigned long vm_commit_limit(void); > > > > + > > > > +/* > > > > + * Denies creating a writable executable mapping or gaining executable permissions. > > > > + * > > > > + * This denies the following: > > > > + * > > > > + * a) mmap(PROT_WRITE | PROT_EXEC) > > > > + * > > > > + * b) mmap(PROT_WRITE) > > > > + * mprotect(PROT_EXEC) > > > > + * > > > > + * c) mmap(PROT_WRITE) > > > > + * mprotect(PROT_READ) > > > > + * mprotect(PROT_EXEC) > > > > + * > > > > + * But allows the following: > > > > + * > > > > + * d) mmap(PROT_READ | PROT_EXEC) > > > > + * mmap(PROT_READ | PROT_EXEC | PROT_BTI) > > > > + */ > > > > > > Shouldn't we clear VM_MAYEXEC at mmap() time such that we cannot set VM_EXEC > > > anymore? In an ideal world, there would be no further mprotect changes > > > required. > > > > I don't think it works for this scenario. We don't want to disable > > PROT_EXEC entirely, only disallow it if the mapping is not already > > executable. The below should be allowed: > > > > addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); > > mprotect(addr, size, PROT_READ | PROT_EXEC | PROT_BTI); > > > > but IIUC what you meant, it fails if we cleared VM_MAYEXEC at mmap() > > time. > > Yeah, if you allow write access at mmap time, clear VM_MAYEXEC (and disallow > VM_EXEC of course). This should work but it doesn't fully mimic systemd's MDWE behaviour (e.g. disallow mprotect(PROT_EXEC) even if the mmap was PROT_READ only). Topi wanted to stay close to that at least in the first incarnation of this control (can be extended later). > But I guess we'd have to go one step further: if we allow exec access > at mmap time, clear VM_MAYWRITE (and disallow VM_WRITE of course). Yes, both this and the VM_MAYEXEC clearing if VM_WRITE would be useful but as additional controls a process can enable. > That at least would be then similar to how we handle mmaped files: if the > file is not executable, we clear VM_MAYEXEC. If the file is not writable, we > clear VM_MAYWRITE. We still allow VM_MAYWRITE for private mappings, though we do clear VM_MAYEXEC if not executable. It would be nice to use VM_MAY* flags for this logic but we can only emulate MDWE if we change the semantics of 'MAY': only check the 'MAY' flags for permissions being changed (e.g. allow PROT_EXEC if the vma is already VM_EXEC even if !VM_MAYEXEC). Another issue is that we end up with some weird combinations like having VM_EXEC without VM_MAYEXEC (maybe that's fine). > Clearing VM_MAYWRITE would imply that also writes via /proc/self/mem to such > memory would be forbidden, which might also be what we are trying to > achieve, or is that expected to still work? I think currently with systemd's MDWE it still works (I haven't tried though), unless there's something else forcing that file read-only. > But clearing VM_MAYWRITE would mean that is_cow_mapping() would no > longer fire for some VMAs, and we'd have to check if that's fine in > all cases. This will break __access_remote_vm() AFAICT since it can't do a CoW on read-only private mapping. > Having that said, this patch handles the case when the prctl is applied to a > process after already having created some writable or executable mappings, > to at least forbid if afterwards on these mappings. What is expected to > happen if the process already has writable mappings that are executable at > the time we enable the prctl? They are expected to continue to work. The prctl() is meant to be invoked by something like systemd so that any subsequent exec() will inherit the property. > Clarifying what the expected semantics with /proc/self/mem are would be > nice. Yeah, this series doesn't handle this. Topi, do you know if systemd does anything about /proc/self/mem? To me this option is more about catching inadvertent write|exec mappings rather than blocking programs that insist on doing this (they can always map a memfd file twice with separate write and exec attributes for example). -- Catalin