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 4A62DD78337 for ; Mon, 2 Dec 2024 17:28:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DB8E6B0085; Mon, 2 Dec 2024 12:28:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98A326B0088; Mon, 2 Dec 2024 12:28:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 850DA6B0089; Mon, 2 Dec 2024 12:28:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 679956B0085 for ; Mon, 2 Dec 2024 12:28:32 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E9A58C01ED for ; Mon, 2 Dec 2024 17:28:31 +0000 (UTC) X-FDA: 82850702760.07.D2869DE Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) by imf04.hostedemail.com (Postfix) with ESMTP id A58B84001B for ; Mon, 2 Dec 2024 17:28:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=L4PyDLWs; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf04.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.42 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=1733160504; 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=I4g52UpJ3PmxcvI/j7zwPPdBS0T11At54rD3c1xjjOY=; b=wut7I52JoA4+SkYgHMSInThzANC/Kp0SP56qwfDjvFRwUDEKwea6jME/hWglKRizeueEE4 ylElQsVjvbbrindvO53ee15GyoDdGfsKOC5rbY4bWgegXCkJq9/BfmT/KszT5IBE/ViQbF OWro293n56h85efr512TahdRlwSEBLw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733160504; a=rsa-sha256; cv=none; b=p1DaemxWVAONQ06Y/hn5705ZGwsHkAH0srwGF0Nbh3uUhihCff0po5AwpAY9G9xFnM90q5 7wVk0FxMOu7bj6Ou21K08TNlIRB226Bvg9App8cuvwI0wr4CnDTuUs7eMNkuIwfNtLlo/V QfUnj6HL3FRpei8KDG9IGL8aiyFCqxA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=L4PyDLWs; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf04.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.42 as permitted sender) smtp.mailfrom=jeffxu@chromium.org Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-2964ebce88cso188901fac.3 for ; Mon, 02 Dec 2024 09:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1733160509; x=1733765309; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=I4g52UpJ3PmxcvI/j7zwPPdBS0T11At54rD3c1xjjOY=; b=L4PyDLWsgnZ4eKejIE04qD5PxbNU7wSoWzzBC5LXk8e+VDuaZpekaizjBM9iT7189x rr1r5eD66vn0HnmysusinsqtyX3vuvcW817qdjVokDDjhFss21OhkSb5CpivBptJbI8l aFdCYY9YWqL+WBMNvSYTUSZn7ZI3wEREMmHUo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733160509; x=1733765309; h=content-transfer-encoding:cc: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=I4g52UpJ3PmxcvI/j7zwPPdBS0T11At54rD3c1xjjOY=; b=uhBYfsGa/KmgSNJbzKKK2m/3mwGM2FAMXxKHCYfuvScTVobmiRDFQA+6NnplKHBaZ5 V+FZSJEmPwJcDsDVa2YcDvayDqm4WDO4oEHSVG3LRpnFS8mj0RcP3t3rrFZ9QxrXhK+V 0r/azVlqH38yULzJXI0S4ape6iCbJAdDv5jNKUacJOlyaGdzCxQJ3x+G5XqfbZYIb6Bf 2+9/Tj+UkoMdHxD4pus0j25AUq+VXs8EEYK3/UEFWJ6epZEE43tAEwo7Rpe2CFd49uek c/A1fucXyAcYSWOemCuz3oRD/jntqWTpPyotdjoD4Y2uCqkDAa/RPL7/kavYw3H9s2Wj VE0Q== X-Forwarded-Encrypted: i=1; AJvYcCVpttPLi93+AUgQoA4HV4fuck3BQl+mVJ6/9JP7djuDNU81PMbZwhIRaXqPK4294A+vcvpKXlG46Q==@kvack.org X-Gm-Message-State: AOJu0YymIffCX/LXtxObCkCewlquNzNpq0zQdKk2gWUNHB/ACRSd6PNd ZLcHmijveOOSTxs7Sn96WfoMExWFmNRZAMEvjaS795L9NKHnKmJVb8FoUITNgCzs/t6dBh0z+Cx ZTXz8oww/g9T7bxLo98sEL9808fQ7ejzDfY1Z X-Gm-Gg: ASbGnctodVoy8v3LCIaaxP8BCXtKNrN4AYYZ/mVfDvTnZ89/vZtVUyWOuvtJXyaYc/L OxMd/CGd8HOGpQU3vbfgnlP84mlqy+nLhQD2NJ3+ualpmzy5Xqrv+jc84Ebs/ X-Google-Smtp-Source: AGHT+IF0l7ckRLP+aVl+IekfkudYe/vLczB8xykS3zl9D27IHSlG37LSEt2alDzPQKCTxcNozOrr3kQuCvLEOD1SXnI= X-Received: by 2002:a05:6870:170d:b0:295:c1ca:b99a with SMTP id 586e51a60fabf-29dc3fbe9f0mr4690677fac.1.1733160508981; Mon, 02 Dec 2024 09:28:28 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <7494c3aa-378f-4bb6-bc44-59ea49ccc5e6@lucifer.local> In-Reply-To: <7494c3aa-378f-4bb6-bc44-59ea49ccc5e6@lucifer.local> From: Jeff Xu Date: Mon, 2 Dec 2024 09:28:17 -0800 Message-ID: Subject: Re: [PATCH v4 0/1] Seal system mappings To: Lorenzo Stoakes Cc: 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, Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, Vlastimil Babka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: e64pcu6r93ns4jbjbcf36xhoc4qrh6e7 X-Rspamd-Queue-Id: A58B84001B X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733160496-486824 X-HE-Meta: U2FsdGVkX19SKhPGhwMrw4H12bv9o2otuzTUgOjyj6A3YZ4MVWmlca+lYGf/MDKiRliT++s1hnnJwE9R+JbWP8jg4Mgg+Vi4ZtWrI5AkVcrExkviEXp8/US31RbfRBlSUNb/YtG4Ug1VxLTt/90QXgByPLfHgUwNEVSSJW9dEEYtps1ZvKvTJHYtfB8fZuHzBE1tF1F2G3h1IfLjEcRuBESQpNN95uWg8J4IRlG6RA9SZmIBqe0P7ibVURm7QQ+ihwKJB6lVOXjXHNKS9WgpWt7Ss1JesbdD6gqQqwOEoXDWB7NwR3IIM/4f6m8nZR9cgajWEXZ3Dke02C7PaKFvWRIovwLEAejw3uhEzZVpgqQNBejDlz8f++HFdBjfsIA5lasB5Qe1QC9HWRSifFrDcA6GyskQrw18WfFX56QV5MNu35qUGWImWJia3ZxyX2Sm4xSddAklOylRkriIsA/j2cehZRmzGT7tbhc5A5LRigI40blwGJu0MOAGrvshz1qUMv5dkCbFXAAKyiKZZIILCULIddRINpyLUmmCGznEkVQ8xiQAxZycupIOf8sQTzPLKKHgWHU8UUdhgZfUz2Wyt/UfyT6eLwAZeaJCZj3xAmKJyOuvXnETWl2DiT8J52CnVP08Mjg9IlM4x80swNK3az87ehrhdP/pFcfMQhCM854yvsIXu1eG70lPWV78CVOVPuM/qBVAjJ/atOrqoglIeIkhzHmkKSOf+MOs8rEEWOibY4etwiUqMc9esHJnsMIoJVIUxS2HRiwxxx0agEhoqCD3rj4O0jupqFZWMkrWcyO2HERcotSatO53xzKpZdqo+fNSNvrp+ZqmNEmIzAsJ1udT8boHSYQhGj1V6XyUZ4PQmsXy3hed2GdTy07u7ytEZxwse4Ms34lEwSLIlWEh5aG6uE45mRmMVQ7p0dxWQ8u48gNqW3Poi3Tbizs68YFVRy5bqJ1nFbWIB6pOF+7 gj1XHvGy d9e5rlUlzROGGoSKA1i1QwRg5yVbUDOz00KLW5us1s4HMVkgocXTXcY47nnoezvF7k4avCLJ3yzR3yUyxiVoiEyLp+i/oSIgmZb+S6PLgNrBd5QpzWrN2IYBE9gclLsaKyU7chyBfpWTUnSJa5BcxC1DCXtA72uJCSKEGBcgi7On0V6pjQcis59Svohn2nC29DozVEhnApS9sp4xRGGcvCFn5cCQEXDe+OCvBn71DAqtd/tWtsvuBlH7ypN0k9W+2vDlVSk7JrLkSP1iwHmPBYqUeSMU0RrNRaV3sKKcyQSp1AeW7ITcciD24ndKlqeN+R8tmMYafA7MZ9WAJ0VKFWNbhrtU2DpoVt+SwtMDte5LyihiiQAKXR9Vxbokpv593CbWAfT+s3obWiH/BOMGjczxftvDC+fVubqBeM00kTvm3q7c0R2+3qXDS6A== 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 Tue, Nov 26, 2024 at 8:40=E2=80=AFAM Lorenzo Stoakes wrote: > > +Vlastimil > > Jeff... :) > > Please review > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > You didn't cc- mantainers of code you are changing. And you reference my > name without cc'ing me here. I'm sure there's some relevant Taylor Swift > lyric... > I apologize, this shouldn't happen again. Thanks for reminding me -Jeff > > On Mon, Nov 25, 2024 at 08:20:20PM +0000, jeffxu@chromium.org wrote: > > From: Jeff Xu > > > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > > > Those mappings are readonly or executable only, sealing can protect > > them from ever changing or unmapped during the life time of the process= . > > For complete descriptions of memory sealing, please see mseal.rst [1]. > > > > System mappings such as vdso, vvar, and sigpage (for arm) are > > generated by the kernel during program initialization, and are > > sealed after creation. > > > > Unlike the aforementioned mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime [2]. It is sealed from creation. > > > > The vdso, vvar, sigpage, and uprobe mappings all invoke the > > _install_special_mapping() function. As no other mappings utilize this > > function, it is logical to incorporate sealing logic within > > _install_special_mapping(). This approach avoids the necessity of > > modifying code across various architecture-specific implementations. > > > > The vsyscall mapping, which has its own initialization function, is > > sealed in the XONLY case, it seems to be the most common and secure > > case of using vsyscall. > > > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may > > alter the mapping of vdso, vvar, and sigpage during restore > > operations. Consequently, this feature cannot be universally enabled > > across all systems. > > > > Currently, memory sealing is only functional in a 64-bit kernel > > configuration. > > > > To enable this feature, the architecture needs to be tested to > > confirm that it doesn't unmap/remap system mappings during the > > the life time of the process. After the architecture enables > > ARCH_HAS_SEAL_SYSTEM_MAPPINGS, a distribution can set > > CONFIG_SEAL_SYSTEM_MAPPING to manage access to the feature. > > Alternatively, kernel command line (exec.seal_system_mappings) > > enables this feature also. > > > > This feature is tested using ChromeOS and Android on X86_64 and ARM64, > > therefore ARCH_HAS_SEAL_SYSTEM_MAPPINGS is set for X86_64 and ARM64. > > Other architectures can enable this after testing. No specific hardware > > features from the CPU are needed. > > > > This feature's security enhancements will benefit ChromeOS, Android, > > and other secure-by-default systems. > > > > [1] Documentation/userspace-api/mseal.rst > > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkR= kL-NrCZxYAyg@mail.gmail.com/ > > > > History: > > V4: > > ARCH_HAS_SEAL_SYSTEM_MAPPINGS (Lorenzo Stoakes) > > test info (Lorenzo Stoakes) > > Update mseal.rst (Liam R. Howlett) > > Update test_mremap_vdso.c (Liam R. Howlett) > > Misc. style, comments, doc update (Liam R. Howlett) > > > > V3: > > https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@google.co= m/ > > Revert uprobe to v1 logic (Oleg Nesterov) > > use CONFIG_SEAL_SYSTEM_MAPPINGS instead of _ALWAYS/_NEVER (Kees Cook) > > Move kernel cmd line from fs/exec.c to mm/mseal.c and misc. refactor = (Liam R. Howlett) > > > > V2: > > https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@google.com/ > > Seal uprobe always (Oleg Nesterov) > > Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg N= esterov) > > Rebase to linux_main > > > > V1: > > https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.com/ > > > > Jeff Xu (1): > > exec: seal system mappings > > > > .../admin-guide/kernel-parameters.txt | 11 ++++++ > > Documentation/userspace-api/mseal.rst | 4 ++ > > arch/arm64/Kconfig | 1 + > > arch/x86/Kconfig | 1 + > > arch/x86/entry/vsyscall/vsyscall_64.c | 8 +++- > > include/linux/mm.h | 12 ++++++ > > init/Kconfig | 25 ++++++++++++ > > mm/mmap.c | 10 +++++ > > mm/mseal.c | 39 +++++++++++++++++++ > > security/Kconfig | 24 ++++++++++++ > > 10 files changed, 133 insertions(+), 2 deletions(-) > > > > -- > > 2.47.0.338.g60cca15819-goog > >