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 492ACE7717F for ; Tue, 10 Dec 2024 04:12:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C931C8D0001; Mon, 9 Dec 2024 23:12:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1BF16B00D4; Mon, 9 Dec 2024 23:12:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A94A38D0001; Mon, 9 Dec 2024 23:12:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 84DE76B00C9 for ; Mon, 9 Dec 2024 23:12:50 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0DB21A033D for ; Tue, 10 Dec 2024 04:12:50 +0000 (UTC) X-FDA: 82877727828.10.3F2A78B Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf13.hostedemail.com (Postfix) with ESMTP id B6DE120008 for ; Tue, 10 Dec 2024 04:12:26 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vs1xAz6t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of avagin@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=avagin@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733803948; a=rsa-sha256; cv=none; b=W/ULUPe4P766oxQs2FdbS2LjqYpL2MkMLmvK8SzsCYL7lYZdo0ok76cG9lfpvPAFUKpb5i +jURcgdY6PYSycv4/bJnOWgsJAhZCkTFXZdzBdl2J8OOi8LaEWP/s02GYGe/0FzzFAiLnZ V1MZuRISC4PhQmsOd/EnMIyZ+37C/Sc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vs1xAz6t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of avagin@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=avagin@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733803948; 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=lhSJXbd5dcODOekyvOZZ9jDY6cmQtFID8ItdO0O4slo=; b=YJ74JQ/zb4oFWUhkIzXnsAqvWEiYfpXhVNPFrhViaPadI0Xd2W9wiPysEjrcNPcXtgazl/ HBWKYC/U9Pk6zrTE5qiQHnWHY5igO6Lw+I16MZ5jKChkymz90pcmUFN20YqmRvRE4Frbso EemD8tEOGgFS1gpnhLxZAghKFjFvi6E= Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-30167f4c1deso21373101fa.1 for ; Mon, 09 Dec 2024 20:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733803966; x=1734408766; 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=lhSJXbd5dcODOekyvOZZ9jDY6cmQtFID8ItdO0O4slo=; b=Vs1xAz6tn15yY2ezR33/u0YvH0M05tKlM25jif6D7qlmapssb3KYKqkgxtR8r1sbv9 4UQUC7ydziSP7QLFZb94RzB8CoSLI0/O3EHAbGSlQ7MiZJzBt1bTT9RPazRukYOTRMiF NLl+cOu4lWCyqNCcNZLNYswPycdFaWiHui9z1F2iJtrR0TNb+SSj3XJHciHWY3Iyca4S MknqyKMl23Cy9D6vMIIZa2PApaX5JXIBX6kC5RUj5I+rLhv5AoxNxNnJu7GPATvPFx5h uG1f6C3d7niXIfKgnInpE/ggChtksOCNgtbdfqgScePETKSvLLuwVmKDg/3FZT/EaHYJ RsiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733803966; x=1734408766; 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=lhSJXbd5dcODOekyvOZZ9jDY6cmQtFID8ItdO0O4slo=; b=YmnBZftWR2g/2U1L4Dns9YWHy2kBwjUI2ZzXhHtLR/Cc5MqXR29lYUkQcjQAFQGo+L 7DMcJPhmJRahZxRF5US9qFS+rAEUY8cdUFGiqN+bDeXMQzFrMyTyFjO03SEepmWb9oWS GaJvVpMD2+rm3/pHr1LK2aajRXU5oEd87Jranj9A67K5SAL+woTPxzXR0dKxvspjEADz TCY75DGnguY43KCz5grYbPfPZuvFZxVgZivnus/IYKwB1lDoZUHsxWyWyythBUygbtW0 gM5Sp7BWc47FWLgzZ+EetwUxAcU7+1XF65OXEgBaW9CkpPoYpdEW4pk6F59tDk9yfjuC v/Gg== X-Forwarded-Encrypted: i=1; AJvYcCV6Qjv64xv98TD5HkxT+azBuu4Ey5H/frnpGhbLIDRjeOcYLrCo1KLe6NFktLr/HsMqyVV2TykFSw==@kvack.org X-Gm-Message-State: AOJu0YyyrGB0wYqgtQagMHQRvDLtq++FzSGzehYWxQHAfCi0AbkuavXw luVrWQIFpO2mD9wYCfvXBXFtkX6d5Z0VuGeRjVfB1xuLEGin7F0NueAd1VBxRmSiQGm0yunipu5 I63VMx59R2NqOVKL85A18B759Hm0= X-Gm-Gg: ASbGncuCZzHJJtiHxpOxqrHeb1CAI+wcpOtfj5GXd6jUyCeVwYsJd6NI6zzgt2e0HU9 2OsmDcXp/9OP8IdPYZEVXmZZM/6NdzweUF5Pr X-Google-Smtp-Source: AGHT+IGqfmjIKRHlYBEVRB6AunCa6PAIG5SYZ5EV0do7KYm3Jg6zd5a6jxntsUDLYr0N6g38rUiV7l3l29PwO81OqR8= X-Received: by 2002:a05:651c:996:b0:2ff:d49f:dd4b with SMTP id 38308e7fff4ca-3022fb4e932mr7132821fa.15.1733803966011; Mon, 09 Dec 2024 20:12:46 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> In-Reply-To: <20241125202021.3684919-2-jeffxu@google.com> From: Andrei Vagin Date: Mon, 9 Dec 2024 20:12:33 -0800 Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: jeffxu@chromium.org 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, Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn , Andrei Vagin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: otc7911yjmg8rpgwkhzheg9axcqaxgtj X-Rspam-User: X-Rspamd-Queue-Id: B6DE120008 X-Rspamd-Server: rspam08 X-HE-Tag: 1733803946-514803 X-HE-Meta: U2FsdGVkX19FhmoyJpncEsVxlgE0x+mdOE8gV4Uwtt7MrdU0tD/4SbshOhKD8Bq5w+F3pracDdrE/s6YjkzFV0XKvQBpYE1lzBlK1DAIaHSPX57yS/4wcDcUyoMvNHhluuZI+56OTJR7eOR6XBnLYNSJM3Ax9EBIEpVz3kwMGY/SxHXo3BwQ4J7jr07muKSAN0c3t45kwAa+/NXmBSTLSlKBbyDwKLgUd1DiBjArtuYokdOb/GVoEa9WWBYrBpzusEw07ZtemcY9esmzasISphhWDZr6V+yKgp1hTDocaVIIMQm+7z9KicSeC+fPmxF0WkVQczOGtssrD8r47tEY3EVHEwp9HtX+7oAFNubdqRYvmT6fMT4y6pUKOomcn/MM5UGsC1i1VQs3XdXhLa4vbcfr6OmEbdmBHik10mhOLuZYLuUCZVuHgal/8Dq2U0UbReJNOgCsbBDg03dAhj9b2hVewZcIjBJ4Zw26sfUlSyCER/0holZM0mQf3fZ3uK9OBwpIYdNWnM0JR/cdi20xr3i0qpUgs8/j3x/lBNp4quIFcjedSoeP4aTFKX+SCmRJ5mnVzUPbqUcPMM5DfH/GRhQv060VcaXAl06QEKeQexP3Hkl8X8S5by1Dyk4LFQljUzLInn8jCJIrnu1TAz+JY8IaLEaMj4ijLgrGLBVzuO5crPtzCKrsQC2tdj5XfqnTqaK5FrFL2wUB2NOvyfpWTGu8S6LSIgZjLDwsG+QgGB415FZSdNdmopmgMfHqyj4EiWdo4izyNL79wuGyHoSuxc4736H5ozOLkfbkdgB/10s8IXJAjsXwcyoRoxf/vgrKagY7eE4xTW3zKD8JMy8g2Do/aSF58hBJMST0yAhca9ybbFp4miF/r2QnLOIFR/AnqOCXykcUUfGEV/sbZbASRSY2WIBb/Mnr5CSnOOvGk2mOUyONWCETpKr0eZb5fUSVjPHBk9OK099MAy3mDl4 htcIWW6y q9AHo6c8bClwsaZvOniX6fsXXPxskXjVeWooYZSgogxitP5VqjCFtZ7AqvgEzkuY75As05bjjIvUAmCdbzps1XJcsvFIt0PRnN5Lm2JJZcTTphlbODFdJiWHqBTj6ExeYacPA1NuAKcLK9ZUn9I3CdSHNFR1gRTPyyWz59sbQnqM1bxijxlUC32bfV5U8hhfRffah0XZAKVRF4fLFAuN2lzZk2Nb9aMbu23sYUGrgSXPAIx8yc0trHVbHZ1hjM7ibXXqBxPvVvtc01bgE1Ns0izQKdRPcj6sgNTsiB0xDzRBTtdX7b6Ao2OdhUzmUbvLdm8Va9dv5cytBd6YP45RTWPw7gYhFSH0Az6ZrwIdn8WiY/gGpS8TZgpUMrCnjV3BpK9y9yBIBzQzD63rUu1QoT60Qzs5rxwIvfV3b X-Bogosity: Ham, tests=bogofilter, spamicity=0.198280, 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 25, 2024 at 12:49=E2=80=AFPM 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. > ... > > +config SEAL_SYSTEM_MAPPINGS > + bool "seal system mappings" > + default n > + depends on 64BIT > + depends on ARCH_HAS_SEAL_SYSTEM_MAPPINGS > + depends on !CHECKPOINT_RESTORE Hi Jeff, I like the idea of this patchset, but I don=E2=80=99t like the idea of forcing users to choose between this security feature and checkpoint/restore functionality. We need to explore ways to make this feature work with checkpoint/restore. Relying on CAP_CHECKPOINT_RESTORE is the obvious approach. CRIU just needs to move these mappings, and it doesn't need to change their properties or modify their contents. With that in mind, here are two options: * Allow moving sealed mappings for processes with CAP_CHECKPOINT_RESTORE. * Allow temporarily "unsealing" mappings for processes with CAP_CHECKPOINT_RESTORE. CRIU could unseal mappings, move them, and then seal them back. Another approach might be to make this feature configurable on a per-process basis (e.g., via prctl). Once enabled for a process, it would be inherited by all its children. It can't be disabled unless a process has CAP_CHECKPOINT_RESTORE. I've added Mike, Dima, and Alex to the thread. They might have other ideas. Thanks, Andrei