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 8D76DC4332F for ; Sat, 12 Nov 2022 06:11:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89D9D8E001D; Sat, 12 Nov 2022 01:11:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84DF76B00AF; Sat, 12 Nov 2022 01:11:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73C738E001D; Sat, 12 Nov 2022 01:11:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 654F26B00AE for ; Sat, 12 Nov 2022 01:11:28 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1F9C5AC1A6 for ; Sat, 12 Nov 2022 06:11:28 +0000 (UTC) X-FDA: 80123768256.13.9D0C9F1 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf10.hostedemail.com (Postfix) with ESMTP id AE9B4C0005 for ; Sat, 12 Nov 2022 06:11:27 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id f37so11252625lfv.8 for ; Fri, 11 Nov 2022 22:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9ZLvRaeS8y+cZCF03n5SSnu9zu8bM48xjEr/wYSpTlQ=; b=BBKlTL9UNjZg3IEZMt3+y5InaJzZApQ7RNP/Jv9nNrfynKwJRQGV2d/E3Noa+wzkcK 4LwgVlg4VJWXr9uA1oDhdFHpRn5fzKdUD020vrNmhoh/scL73vgFasNgxf0snOAESocl 3KtbwEFaahz+YpOlBHgl3hGiBJRIibun7RIihbxxMgnD3Ssn0oFmna0b6XVKuOA6677e xi8EQ712kwMAvFjW+CMQ/2Dj90qGZ89yDRcwTuwNti1GWsRqnrTW9Wicnv7F3K9BLnK5 4qcVWLEXBRCMenV0CMQPLK2O3j0hriQmFaEaJJDm2Tz7iQmp1oC01gi3GTfbjQmYPzWD QBlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9ZLvRaeS8y+cZCF03n5SSnu9zu8bM48xjEr/wYSpTlQ=; b=7/9Pn2F2Jut+NLKryfBhec0kERJHv5WT+v2bQ4E/VldU+TDXm8YqlrZl8sebpPvm91 sGvEXQYhEUZlwzhyDl/1pLWWYxVjqP3Fb5P8IXkVJBYrEfdWcXH3DwVZplp0LJMeKhKE TYH/q0JomiyF9GJ2ae5SOf2CzHtHefHZa+ts94yDUNxrW0w6k9CrndMUkmK/KXShjy6o GANYJjPBNMwP9X5JzLusZCKoxLT3L76gLjeBAGUpKMcKTIRJoOAvrSP1QthsIRyKQTqY pvVML0mTqTywNnf1/xPAI2lKOwcYHafPpU7tZjC/Gu3nLgbtqsKlelpjCcRnYvweZsG+ RJlg== X-Gm-Message-State: ANoB5plHkkEZ73YTxYNnXi3ZiK2fnUHBjnoZe8klyc+k+uknAFljJNq9 rwP00pgMb+pr/9nw6u/b7oQ= X-Google-Smtp-Source: AA0mqf61PLdv0bjkPFdOk6TopWXuZVrtchqhyLcjmBwmZLffdDwe+Agt8OGIuMn2kPoGJ1zRtu36Ow== X-Received: by 2002:ac2:411a:0:b0:499:4f:2582 with SMTP id b26-20020ac2411a000000b00499004f2582mr1901357lfi.515.1668233485763; Fri, 11 Nov 2022 22:11:25 -0800 (PST) Received: from [192.168.1.12] (91-159-148-109.elisa-laajakaista.fi. [91.159.148.109]) by smtp.gmail.com with ESMTPSA id u2-20020ac258c2000000b004996fbfd75esm705413lfo.71.2022.11.11.22.11.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Nov 2022 22:11:25 -0800 (PST) Message-ID: <45419a7d-04dd-2749-2534-6ba3bbd5d060@gmail.com> Date: Sat, 12 Nov 2022 08:11:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v1 1/2] mm: Implement memory-deny-write-execute as a prctl To: Catalin Marinas , Joey Gouly Cc: Kees Cook , Andrew Morton , Lennart Poettering , =?UTF-8?Q?Zbigniew_J=c4=99drzejewski-Szmek?= , Alexander Viro , Szabolcs Nagy , Mark Brown , Jeremy Linton , 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 References: <20221026150457.36957-1-joey.gouly@arm.com> <20221026150457.36957-2-joey.gouly@arm.com> <202210281053.904BE2F@keescook> <20221110112714.GA1201@e124191.cambridge.arm.com> Content-Language: en-US From: Topi Miettinen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668233487; a=rsa-sha256; cv=none; b=VCaugPdhJ5anubrwoR49YaWvPyShjBUdQJgv+qPVx4T2y0W/MCFuTOfVplot/JGIZpF/eb WxThi9TxYP8jxNNaj9nyLpG77KXLMWZV0a4EenxpZdyqHf3vDsraBGEHRQom5XvB3p6DGS d9hIFov38KWLi4b7PwqI/VummH33q3U= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BBKlTL9U; spf=pass (imf10.hostedemail.com: domain of toiwoton@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=toiwoton@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668233487; 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:dkim-signature; bh=9ZLvRaeS8y+cZCF03n5SSnu9zu8bM48xjEr/wYSpTlQ=; b=wvXDhHW61/0VfSjT35oqw0KL1ru1v5Pjvjmt1Zch1r+qVKNYzIktHoB9b569UY/bl3n7gl uvam8bVju8B6kuOMztAo0YjiRna2m7KbCXbbrC1Sh+3NisaR1Z+DK9ekgu0xDQuuQ3LKFx Lqt9bQqowpcvICPBrqoNwnphOQyPtd0= X-Stat-Signature: sm6z9qqykhzspusaoue31836pktxbta3 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BBKlTL9U; spf=pass (imf10.hostedemail.com: domain of toiwoton@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=toiwoton@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-Rspam-User: X-Rspamd-Queue-Id: AE9B4C0005 X-HE-Tag: 1668233487-163992 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 10.11.2022 14.03, Catalin Marinas wrote: > On Thu, Nov 10, 2022 at 11:27:14AM +0000, Joey Gouly wrote: >> On Fri, Oct 28, 2022 at 11:51:00AM -0700, Kees Cook wrote: >>> On Wed, Oct 26, 2022 at 04:04:56PM +0100, Joey Gouly wrote: >>>> diff --git a/mm/mmap.c b/mm/mmap.c >>>> index 099468aee4d8..42eaf6683216 100644 >>>> --- a/mm/mmap.c >>>> +++ b/mm/mmap.c >>>> @@ -1409,6 +1409,9 @@ unsigned long do_mmap(struct file *file, unsigned long addr, >>>> vm_flags |= VM_NORESERVE; >>>> } >>>> >>>> + if (map_deny_write_exec(NULL, vm_flags)) >>>> + return -EACCES; >>>> + >>> >>> This seems like the wrong place to do the check -- that the vma argument >>> is a hard-coded "NULL" is evidence that something is wrong. Shouldn't >>> it live in mmap_region()? What happens with MAP_FIXED, when there is >>> an underlying vma? i.e. an MAP_FIXED will, I think, bypass the intended >>> check. For example, we had "c" above: >>> >>> c) mmap(PROT_READ); >>> mprotect(PROT_READ|PROT_EXEC); // fails >>> >>> But this would allow another case: >>> >>> e) addr = mmap(..., PROT_READ, ...); >>> mmap(addr, ..., PROT_READ | PROT_EXEC, MAP_FIXED, ...); // passes >> >> I can move the check into mmap_region() but it won't fix the MAP_FIXED >> example that you showed here. >> >> mmap_region() calls do_mas_munmap(..) which will unmap overlapping regions. >> However the `vma` for the 'old' region is not kept around, and a new vma will >> be allocated later on "vma = vm_area_alloc(mm);", and the vm_flags are just set >> to what is passed into mmap_region(), so map_deny_write_exec(vma, vm_flags) >> will just be as good as passing NULL. >> >> It's possible to save the vm_flags from the region that is unmapped, but Catalin >> suggested it might be better if that is part of a later extension, what do you >> think? > > I thought initially we should keep the behaviour close to what systemd > achieves via SECCOMP while only relaxing an mprotect(PROT_EXEC) if the > vma is already executable (i.e. check actual permission change not just > the PROT_* flags). > > We could pass the old vm_flags for that region (and maybe drop the vma > pointer entirely, just check old and new vm_flags). But this feels like > tightening slightly systemd's MDWE approach. If user-space doesn't get > confused by this, I'm fine to go with it. Otherwise we can add a new > flag later for this behaviour > > I guess that's more of a question for Topi on whether point tightening > point (e) is feasible/desirable. I think we want 1:1 compatibility with seccomp() for the basic version, so MAP_FIXED shouldn't change the verdict. Later we can introduce more versions (perhaps even less strict, too) when it's requested by configuration, like MemoryDenyWriteExecute=[relaxed | strict]. -Topi