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 9EB5AD637C4 for ; Wed, 13 Nov 2024 21:38:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 165006B0085; Wed, 13 Nov 2024 16:38:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EE976B0089; Wed, 13 Nov 2024 16:38:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED0A76B008C; Wed, 13 Nov 2024 16:38:46 -0500 (EST) 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 CA89D6B0085 for ; Wed, 13 Nov 2024 16:38:46 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7D6AC1A0CB1 for ; Wed, 13 Nov 2024 21:38:46 +0000 (UTC) X-FDA: 82782385350.26.7995B3F Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by imf21.hostedemail.com (Postfix) with ESMTP id 815301C0016 for ; Wed, 13 Nov 2024 21:37:22 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=bIMQTRlZ; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.50 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731533689; 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=z1HLez0Td9c7uyIaeN8KOf70EzxAV/9Y0VBaG+sRDN4=; b=35cR0YHfAKgybw+L0QRMQsnJvniXcy4iSJmxRYLy52sILGMOncXyIoOyjbKoXOZyl8DE6r mqU4K6O+swdp3reVaiyQJ12sQXTLSW95K1CczHM0QEB2YlPRYtT4utWT6rJglg341NnGIZ stj7s4pbfyuolycvC9qY27AEBxQys8Y= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=bIMQTRlZ; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.50 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731533689; a=rsa-sha256; cv=none; b=MhTX9ZKATQ/wKcPhgj9aXjxy94xrEtVra+O/SVAeZN4TJmteVXqhotjuVLI9M9/Tf4+mwq GiHuML40CkegTXdnNXdNtH8AdUnOqh0HUb/NnoSLfxhJ+ID2RqXCBZ79UJdxRUics9LaV+ ggXtFTjYg2I/Cg2vCyGB/6GigqGajt8= Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-5eb84216a1cso174312eaf.3 for ; Wed, 13 Nov 2024 13:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1731533923; x=1732138723; 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=z1HLez0Td9c7uyIaeN8KOf70EzxAV/9Y0VBaG+sRDN4=; b=bIMQTRlZcZ0y4SjGr4WP3ZaqJJpJBg3bDRAtN+eF80uNo7lf/73sPrZXp0dj31sQl6 cfFGyIwN8RmCxsVGroslIhbMU2yMxxfPD4wDwoF7ZaP9qhNReQo9A8Wg0KYWw5DJx9XC jPlEZWNYO1FTJZxCo+yr7mTXUwIU4ZuoZmMZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731533923; x=1732138723; 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=z1HLez0Td9c7uyIaeN8KOf70EzxAV/9Y0VBaG+sRDN4=; b=a8VkZjQZPaBeBhhK4ikB361cWRyy+MyLD5txFAFZD2y/XvXPr1SrRWSGuFFUCY1WAu x2zO07UuBz8Sm8V2sHXcpi6vD0INPwZQWBXx3WKVJ8DZFQb7iMS9REf4SLeXAbSrO8IX h01IgN+780cTqaerXl8W1zWEl+18rA3zHwfDwccat8QyU4mJ6p32fpYJ9F4W+M4fA1pA 9HS/TkkzVsycnF9kyIVeX9EqHDmKF+Kqz6U4/MNL/4RH2ItAm1b4e8bZCWtEDwz6L1KO kif89PPJocM1AOLTSugEJ6DkTHal7vZrR+B367xYS1EI0UgKZIGtqtmJs83TA1Di7UlS XkCw== X-Forwarded-Encrypted: i=1; AJvYcCUwAfmKHCBD9NFx/d3cZzPj0GMJYYndI1+AC3BDzIeepdrHTpMrzetm0ToH0zHTAXQxDEphHwIh/A==@kvack.org X-Gm-Message-State: AOJu0YxFBBvrg/vB+l9KsVx/6H5Np0u2Pi6uZMKRdl/CGAsFJWw04Pj3 gNmIpUxj0tBqw5Fz2V3BaFN/ZevO9/CvFD984ZLqA5WQzHEvITAqzBarnJTnQlVelojpQwoFzwi YoCY1uek4rSE9xc+wj9C5GJEktkOMcHTco5sr X-Gm-Gg: ASbGncsFH+K2Ekt/2PS+bOj0wAAtNL1F5yoNH9F3sRRNPiYKplrkKcbOqNZEkElLLnh S0//lu0tJJk5ihJKaXX4EjP6yF5aXqRMe X-Google-Smtp-Source: AGHT+IHx0rYafwheHrgh+R02YLA3PsYr8f7geW3TKeFbn9zyqsBnWTS3qCE09qHmhyurf27HCRIU2KpvGII3C/Pg7xA= X-Received: by 2002:a05:6870:8e07:b0:27b:b2e0:6af with SMTP id 586e51a60fabf-295600d07c9mr4371531fac.2.1731533923524; Wed, 13 Nov 2024 13:38:43 -0800 (PST) MIME-Version: 1.0 References: <20241014215022.68530-1-jeffxu@google.com> <20241014215022.68530-2-jeffxu@google.com> <6r5sxlhfujr2expiscsfpdjtraqlvy6k3cznmv25lo6usmyw7x@igmuywngc5xi> <5wpwj5uokivgcwfcpjh7lbi4g64gecsajfn6glghfmc2lvzrgd@2fz7zhgmsduo> In-Reply-To: <5wpwj5uokivgcwfcpjh7lbi4g64gecsajfn6glghfmc2lvzrgd@2fz7zhgmsduo> From: Jeff Xu Date: Wed, 13 Nov 2024 13:38:32 -0800 Message-ID: Subject: Re: [RFC PATCH v2 1/1] exec: seal system mappings To: "Liam R. Howlett" , Jeff Xu , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, lorenzo.stoakes@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 815301C0016 X-Stat-Signature: swd9hm8hhep8nw68yjshsrm7gher1oga X-Rspam-User: X-HE-Tag: 1731533842-901185 X-HE-Meta: U2FsdGVkX1/93Jfh2xiEEeYYljCJ2FfjXTclRkjPsPlXuXOvL+vFRinO7ugn5LRHoYh7nbGO4n5Sb4NCY7qF8MDCEzYX7xnLQKSN7c9Lm9kLvajs51hBpQKDATPxqISDrbNlfQButiJ8vqAinq07EDckfhEQGex9oKUxkyzHIJcNMVYJzkqy4P7tEctL0+Dt0ERVac8p7v0P8HgkrHs9ls+6Jy7V0ArK8Xk7+Kr0MiOaVsnrKRADl0gsv1D0wpIqORdr2wKxJzmp57CS2NwXJ2gQVKCnmk/IeHzCo+3iJxAwIjqBvKGFqv+c20A1BLSnxKuZ2cbkRfcP7nRiIJ42cS+tbzpipUrtH2/sYe1lxjEpy3xL16thSUTJ8wAhAjr9MHunr38Xb9auZp6i9sQJt7GKOEXFcaipQl2zRVAsYvfjDc2KWLJx4QJvDG+h7tjWkm5ojYFqXQrPiF90iV4V13R/AhnahhMdPBNWpeD0rXz3M3nxtTHFvxpPmBlqFOIe2uYunIyUWr4f+e4tpNTNZa3qV7/0Jb3OG1x19kzN+N6mmqONU3b/cr+HFdmUR1ou9vxiKP3pN186lOYCNQT394Uwwq8vEqq+nTQUvtPRc6yI10PCVFTv53ydxBroYAfg3HNP/JnZXJn9EH+N7ireGuvp0ntQjAHBgmCvr2rhMXTB8FMf2pvGns7BCrxBsuYerjTbinGubex74DglwhTXwFu32T9BAArQJn81eXdHH7y01sVzYsbRJhZ3XXZO5WcibU7/lz8kqt09l1+t6UWlS7qEtzm8sTV/HeZM/g+3q0XNIUVqboGGghejJej88mX8tajMRRjW5iz7L4M19f/DFx3geLGNfE8aH35tQryW/icTBuUp342B3yshR5oHVdIZaYw7ujg5OQpn6qhjqb6PxdCCfd0obRQJwXf3iHYFkw1ZeneCbVT9hPq3jGZEN/s7OfchzK5tlJ5GIhkk3iE egPig1U0 f9Lp9J4kLB+ls+ov9QDLQk1sN74UC9URVkmO/3rNap6j0f8vPq7omFxBMlUHdShoY5LbgfZ46v7cktacQbPjg7jGEjJ1/FmWlUPikoWk+wj9c3+cSf6bBmUPNKjRU2N4Gip/6rdxC7zoONsgqwBVtcgQ+S6T9WvDV6zPFVCG6T5R+5WkM7V2MWyGM/nruLtzGS0pBk9AWqetAEoPO27JgIRCcen+OKHDZIUxhStoRS9RQOFpgMANBdQCY+GxMl4GaL4MRbwbGjOgZtCP5uoXjmRZ+BMJd5ymOOMdPWFG5Ysqa5EFEki6Flgkr8bQnivjfclse4c8El2ymWBfNw8jzeGFFMqQCATp2nYkk 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 Mon, Nov 11, 2024 at 2:35=E2=80=AFPM Liam R. Howlett wrote: > > To make modulization better, I can do below adjustment: > > if (seal_system_mapping_enabled()) <-- implemented by fs/exec.c > > add_vm_sealed() <- keep in include/linux/mm.h > > > > However, if you have a strong opinion on this, I could move the > > parsing logic to mm/mseal. > > Yes, please move the parsing logic together with the other mseal code. > Sure > > I am not sure what one you are renaming or what these functions would > do. I think you need to look at your overall design and try to fit it > into what exists instead of putting a call in a wrapper function > (_install_special_mapping) to alter an argument. > Please see V3. > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > > > > index 57fd5ab2abe7..d4717e34a60d 100644 > > > > > > --- a/mm/mmap.c > > > > > > +++ b/mm/mmap.c > > > > > > @@ -2133,6 +2133,7 @@ struct vm_area_struct *_install_special_m= apping( > > > > > > unsigned long addr, unsigned long len, > > > > > > unsigned long vm_flags, const struct vm_special_mapping *= spec) > > > > > > { > > > > > > + update_seal_exec_system_mappings(&vm_flags); > > > > > > return __install_special_mapping(mm, addr, len, vm_flags,= (void *)spec, > > > > > > &special_mapping_vmops); > > > > > > > > > > If you were to return a flag, you could change the vm_flags argum= ent to > > > > > vm_flags | mseal_flag() > > > > > > > > > passing pointer seems to be the most efficient way. > > > > > > I disagree. Here is the godbolt.org output for gcc x86-64 14.2 of yo= ur > > > code (with some added #defines to make it compile) > > > > > > seal_system_mappings: > > > .long 1 > > > seal_system_mappings_enabled: > > > push rbp > > > mov rbp, rsp > > > mov eax, DWORD PTR seal_system_mappings[rip] > > > cmp eax, 1 > > > jne .L2 > > > mov eax, 1 > > > jmp .L3 > > > .L2: > > > mov eax, 0 > > > .L3: > > > pop rbp > > > ret > > > update_seal_exec_system_mappings: > > > push rbp > > > mov rbp, rsp > > > sub rsp, 8 > > > mov QWORD PTR [rbp-8], rdi > > > mov rax, QWORD PTR [rbp-8] > > > mov rax, QWORD PTR [rax] > > > and eax, 2 > > > test rax, rax > > > jne .L6 > > > call seal_system_mappings_enabled > > > test al, al > > > je .L6 > > > mov rax, QWORD PTR [rbp-8] > > > mov rax, QWORD PTR [rax] > > > or rax, 2 > > > mov rdx, rax > > > mov rax, QWORD PTR [rbp-8] > > > mov QWORD PTR [rax], rdx > > > .L6: > > > nop > > > leave > > > ret > > > main: > > > push rbp > > > mov rbp, rsp > > > sub rsp, 16 > > > mov QWORD PTR [rbp-8], 0 > > > lea rax, [rbp-8] > > > mov rdi, rax > > > call update_seal_exec_system_mappings > > > mov rax, QWORD PTR [rbp-8] > > > leave > > > ret > > > > > > ----- 48 lines ----- > > > Here is what I am suggesting to do with replacing the passing of a > > > pointer with a concise "vm_flags | mseal_exec_flags()" (with the same > > > added #defines to make it compile) > > > > > > seal_system_mappings: > > > .long 1 > > > mseal_exec_flags: > > > push rbp > > > mov rbp, rsp > > > mov eax, DWORD PTR seal_system_mappings[rip] > > > cmp eax, 1 > > > jne .L2 > > > mov eax, 2 > > > jmp .L3 > > > .L2: > > > mov eax, 0 > > > .L3: > > > pop rbp > > > ret > > > main: > > > push rbp > > > mov rbp, rsp > > > sub rsp, 16 > > > mov QWORD PTR [rbp-8], 0 > > > call mseal_exec_flags > > > mov edx, eax > > > mov rax, QWORD PTR [rbp-8] > > > or eax, edx > > > leave > > > ret > > > > > > ----- 26 lines ----- > > > > > > So as you can see, there are less instructions in my version; there a= re > > > 47.92% less lines of assembly. > > > > > vm_flags already run out of space in 32 bit, sooner or later we will > > need to change that to *** a struct ***, passing address will be > > becoming necessary with struct. Since this is not a performance > > sensitive code path, 3 or 4 times during execve(), I think it would be > > good to start here. > > No. > > I have pointed out why this is not 'the most efficient way' and you are > now switching your argument to 'this will be needed in the future'. > > Please fix this. > Sure, updated in V3