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 93A63C48291 for ; Fri, 2 Feb 2024 20:14:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23EAD6B0092; Fri, 2 Feb 2024 15:14:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EF4E6B0093; Fri, 2 Feb 2024 15:14:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DE2D6B0095; Fri, 2 Feb 2024 15:14:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F33276B0092 for ; Fri, 2 Feb 2024 15:14:46 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 82940120F03 for ; Fri, 2 Feb 2024 20:14:46 +0000 (UTC) X-FDA: 81747966972.06.5BA0476 Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) by imf13.hostedemail.com (Postfix) with ESMTP id CADD720015 for ; Fri, 2 Feb 2024 20:14:43 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Dd+Asv2v; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706904883; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=xqTNsAxhlA2YuESAciCqyaWHxO/Ad9sPBhytH5Lgwoo=; b=MNKXzOS3yz6OSXaFyX+wb2l7Hi/liA+cV5IAdkZVLFVsWOVhjtFz/rwAWf+3pojchNYKnK 2AnzU8dutBTJ9pt3OG/ll9NMX9YXDMh4ZdJjDcavus2XJMDoCpKHdP7MrVUA0Htr/WHNua /2n79o+3p3YPH41FwYG9+RLZHeX6+WM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Dd+Asv2v; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706904883; a=rsa-sha256; cv=none; b=x/wac60ZCdTsLYS61H7frSvtlYN0G0HdJssQX9WIKnzhmPxhOw3xwQfSUZpVxnJo+4XTQJ bvqdcDZeXRDMQpTa9Fj/cHDYT3u1qthdizgKf1uDiVG/cvz2Nks0WnW6c8X0AX1qQBTAv/ wSARt/BtCnuVU0boYPAbDjyrtSjnZDI= Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-2143a96d185so1291707fac.3 for ; Fri, 02 Feb 2024 12:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706904883; x=1707509683; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xqTNsAxhlA2YuESAciCqyaWHxO/Ad9sPBhytH5Lgwoo=; b=Dd+Asv2v3rdf+fL0BDUFid7UDHiMlsSgeYd+R1tzSSgPrR4OkbMHuMMNSnJ4CbShJ5 W7XHXIRraD+TlC1SDBR8gLYTO8gOk/pBx+DCd4WHI/NsHLUZQFWy6pb/ZiqGpBnxs12I Qyn2QUQMyM+/ZXFdZY+GMxBs9xTqwaBOSoUME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706904883; x=1707509683; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xqTNsAxhlA2YuESAciCqyaWHxO/Ad9sPBhytH5Lgwoo=; b=a37SXg4vALs5wGsSi2V4HNNaA+lxmFeP4h4uhrluO0TiVcKiPIOLoB5g9l9vu0KQmy SRvpgopNiyYUxm0UEGFFtYeNMijc0bb/QIhyAluysDhLbdIcshZWLUOT8XiZEm/k/puC apbkz/KWOQveliZhAYd+IZmKnnRyNQgMhe53IN3Rc/0o8CCV8KYIQZZqZxkON4KNSeUC h9WWTmKy/67jgY0xowQQa3j5+y59gEpQwk+8AMvG3sCOD5SI0+/VUarghHEIQ5k5d+kx kcHYNHvq81XwTn7Zx1SvevB2gMJyFUtWXkQSXMNn/C32acZl/g2eCYI8Wutpgd10CBm8 ByAQ== X-Gm-Message-State: AOJu0Yxv3BI3RtnfZZre4p1bUeuRzQKl/hSOQcWJvI37p13N4TV3AvjA nM1o7TSug9Vt3yInxiNJfI3dLJlNkdo5X8jlc2MNHf86Q/0qlvme8uEe1r+d8LXooyO5V2IfdlF zPUs9BNqnQetytrrLIS1HdNXzTqjCH6MMhE9F X-Google-Smtp-Source: AGHT+IFXZk9NEru0SMUk4ua6BbcA0uxSwiHUSIrvMKOjEmnDZTutfkU8uby9d0bZyeAELY8c6gc2tX4NnGWiDQ1x4nA= X-Received: by 2002:a05:6870:3920:b0:219:3d70:97c4 with SMTP id b32-20020a056870392000b002193d7097c4mr863481oap.20.1706904882945; Fri, 02 Feb 2024 12:14:42 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <20240202151345.kj4nhb5uog4aknsp@revolver> <20240202192137.6lupguvhtdt72rbr@revolver> In-Reply-To: <20240202192137.6lupguvhtdt72rbr@revolver> From: Jeff Xu Date: Fri, 2 Feb 2024 12:14:30 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: "Liam R. Howlett" , Jeff Xu , Jeff Xu , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CADD720015 X-Stat-Signature: bwmt3ba1kkbs79kcuu77wrhpf9xhu8b7 X-HE-Tag: 1706904883-942420 X-HE-Meta: U2FsdGVkX1/dfK9djV3oIX51lis3ovcBGg1B3o+qI7fB3qJpldXRzjWPC0kKj0moQ5Z/6fvbO/COayCvSEj3udKi98pUxgljWeYDE6OPO5HaG4c1gP/ouAeEOzu5xhoeFLB0gwPlWc/rFsc6Crfr25LsbGSqIaFwKRzljjzcVYj2viBGFRQxn6fJDIlMgl/S7P8e0HIdO+C6qiCdCCO78Icwi+Eoh4CLawa6amfb7PhCQnrlPDgyqkDBlP0livOfheFsmtPWI/yLJPRH/ZrB8jcCmp08xNiEVpzaWk7DQKkAax2LP7iG5Df2+tkza41jWJUNk0Pk4Xz2xxjR4jAgfuZkq/AJLeZqd4p3paz2zwfi2PGhOjCVmvSngWNv3+n28Ay6m7ZFYvipoS4deG+E23G8YnkEwrJOqFtHQDpfaeNvUYo+tNnz+RUE+wa5/elsadWBoixXVApYhCTTosmmk+d6hdcWCO39WMeKCjtHr1j0/7fFOBCjIdhIxJZb0Z2V+blXQfI0wYoTCTO1tliFPhuhiatQXCwYsYxVIwn1TBQvGXhq/8/zVrX01f25zs47cKYNdQL4aZl2oQaGKTaE5RRK6w79pc8DskgwmL0Cjy3V+pk0vN5EokLXcj+gUY3bxrhFGahMj7q5dYE57YGVzFP+uctWokSPer8diGENrrvoHzcH5KO7KKqxFoL1Mn8eySnY531uvSxRjgsowRsTdWcwiEqPhXFmGlb4ZEcCEOXDH4NIPHHLpiITdsnjde5JEPA//Rh99SbjLDS+2jH0FXLtNqhmoIHcGDLeBbiO08A7XStKcjTHsMAI8BSwEPoCnWl5pqvZHEf3SKpnvrbbdTT0kSFeNuMP6uzcXwxs/UsPGE1l6O04Ztg3jnFAF5Z/ai0OdQDml/X4JGZxpHcRunwAYFDaQh27CBXUKOA8v2V7Z/DOGOHNcFF9R/cWHhSQY3nWSF+lfuqhW652P96 wsfWLxXk Om3Q+IMwjuo96RJ9uW5ovGS7LVgd7pNgQPrZAQ2Z48a3LO39L1KWX0zFOBvLsh3WtnZHlcTlfYynK7kM/ruvLm8JngRROknjjse2Yl3mYPXyMGutl3EW+BB7qNw83FzyYi+eEjOIFYVBBVdd72bkEGZRlPqbLOlYp4giCaL/pdR/nnj4hIT9ih3tkkx7o5TG1DwVCbi8n8Im2UFK3Tht8bQms4t+Mu7v1QnfbGGqyScJTBDH+RVnGOcHitnIB2hhEiztQboXQe9EPa4YORpHO+Q10ryZbzNaVTb6Ob5CLknzj8dFeVHtyBfslXyztPXBUsJBOBGZsxggCfUzOEXeFbvB6g/8gCqPx9Ok8ngGT6Wb1M8szReUEoA0hp39EXAjtXqde 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: List-Subscribe: List-Unsubscribe: On Fri, Feb 2, 2024 at 11:21=E2=80=AFAM Liam R. Howlett wrote: > > * Jeff Xu [240202 12:24]: > > ... > > > > Provide code that uses this feature. > > Please do this too :) > Yes. Will do. > > > > > > Provide benchmark results where you apply mseal to 1, 2, 4, 8, 16, an= d > > > 32 VMAs. > > > > > I will prepare for the benchmark tests. > > Thank you, please also include runs of calls that you are modifying for > checking for mseal() as we are adding loops there. > It will includes mmap/mremap/mprotect/munmap > > > > > Provide code that tests and checks the failure paths. Failures at th= e > > > start, middle, and end of the modifications. > > > > > Regarding, "Failures at the start, middle, and end of the modifications= ." > > > > With the current implementation, e.g. it checks if the sealing is > > applied before actual modification of VMAs, so partial modifications > > are avoided in mprotect, mremap, munmap. > > > > There are test cases in the selftests to cover the failure path, > > including the beginning, middle and end of VMAs. > > test_seal_unmapped_start > > test_seal_unmapped_middle > > test_seal_unmapped_end > > test_seal_invalid_input > > test_seal_start_mprotect > > test_seal_end_mprotect > > etc. > > > > Are those what you are looking for ? > > Those are certainly good, but we need more checking in there. You have > a seal_split test that splits the vma by mseal but you don't check the > flags on the VMAs. > I can add the flag check. > What I'm more concerned about is what happens if you call mseal() on a > range and it can mseal a portion. Like, what happens to the first vma > in your test_seal_unmapped_middle case? I see it returns an error, but > is the first VMA mseal()'ed? (no it's not, but test that) > The first VMA is not sealed. That was covered by test_seal_mprotect_two_vma_with_gap. > What about the other system calls that will be denied on an mseal() VMA? The other system call's behavior is kept as is, if the memory is not sealed= . > Do they still behave the same? do_mprotect_pkey() will break out of the > loop on the first error it sees - but it has modified some VMAs up to > that point, I believe? Yes. The description about do_mprotect_pkey() is correct. > You have changed this to abort before anything > is modified. This is probably acceptable because it won't affect > existing applications unless they start using mseal(), but that's just > my opinion. > To make sure this, the test was written with sealing=3Dfalse, those tests are passed in the main (before applying my patch) to make sure the test is correct. > It would be good to state the change in behaviour because it is changing > the fundamental model of changing mprotect/madvise until an issue is > hit. I think you are covering this by "it blocks X" but it's doing more > than, say, a flag verification. One could reasonably assume this is > just another flag verification. > Will add more in documentation. > > > > > Document what happens in those failure paths. > > I'd like to know how this affects other system calls in the partial > success cases/return error cases. Some will now return new error codes > and some may change the behaviour. > For the mapping that is not sealed, all remain unchanged, including the error handling path. For the mapping that is sealed, EPREM is returned if the sealing check fails, and all of VMAs remain unchanged. > It may even be okay to allow munmap() to split VMAs at the start/end of > the region and fail to munmap because some VMA in the middle is > mseal()'ed - but maybe not? I haven't put a whole lot of thought into > it. If you are referring to something like below [unmapped][map1][unmapped][map2][unmapped][map3][unmapped] and map2 is sealed. unmap(start of map1,end of map3) will fail. mmap/mremap/unmap/mprotect on an address range that includes map2 will fail with EPERM, with map1/map2/map3 unchanged. Thanks -Jeff > > Thanks, > Liam