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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 186CAC4332F for ; Sat, 12 Nov 2022 06:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ane1fox9Wij/oGg1ncD+MsDrIwtZjhkEuImi6Vw2ZbI=; b=4F3xKwT/XykJJ3 0FfafIFRm8OEXpUoUI20WOyj/yATlahMG1VbxJxss6aLPyURijcYmgktUPfuNNNCLy1JwkGIFcalo BxYwYH61cCU6oztja27lA5fScNPkwb0xW5B51MBliVUBJDtXjplQ2tfPkuBa26MXhk2spcopQv5Hb aXfBnVY8x3jlZZKRVUDtd5jhAf4H+N/yg4SYqpOp3holwVEf9fObzVG/AbR+w6ZRS+mL2oUDrQGV8 K1csUU0MrPht+Ub34W9hQ1vPdqnoXcYZ1fe13isxfZU8BeqJa4ZKruoaFao71OGgC+EnwknTNBsdZ qTyHfoH9FuJe0bcwpbwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1otjjm-003bpO-4F; Sat, 12 Nov 2022 06:11:30 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1otjjj-003bhQ-2D for linux-arm-kernel@lists.infradead.org; Sat, 12 Nov 2022 06:11:28 +0000 Received: by mail-lf1-x12b.google.com with SMTP id a29so11243061lfj.9 for ; Fri, 11 Nov 2022 22:11:26 -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=mzaJNOAmCqrdpns1F+z/gkb9Mi2UjizO3OgEyPf26HkBhu8HRE8TWfA6aNKQprq4k/ wuvE/BQl4VGGMZrN6BJLvjRMy867pp97/9P5vW+yBavaVAsi952Fk+c1SwZj//8zGgqR KmUY+Jd+fpF/NnVNB1EeFUMRhA5dgLy7ptehtdUKA3OOtroup+Q+csKn4SBWW31OWWt3 JXI4Av1qMv7X2m29GoxixVMFKOMJIR+1UBGl/IA9O/gjx7Pqjy5k2nZMSa/FDwCB5WDu vtTzzF1sQkQ/JBblautt4c+iv+tpXLvVv68Lj90HF6hG+xpqCVtL2zMoA9gjfKftvaIS 1vTQ== X-Gm-Message-State: ANoB5pkUArd8LiU4lEj6dFrHE/cemcPywae4ASCmls++dbMiaD9FE3gn JdG6VptJTOZINWXU/OSRWU8= 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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221111_221127_140385_D595570A X-CRM114-Status: GOOD ( 26.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel