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 A8A27D6C2AF for ; Tue, 19 Nov 2024 23:49:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DB4B6B0088; Tue, 19 Nov 2024 18:49:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B3246B0089; Tue, 19 Nov 2024 18:49:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 279B46B008A; Tue, 19 Nov 2024 18:49:50 -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 073646B0088 for ; Tue, 19 Nov 2024 18:49:50 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 82DB21208AF for ; Tue, 19 Nov 2024 23:49:49 +0000 (UTC) X-FDA: 82804488648.18.6A21A16 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by imf01.hostedemail.com (Postfix) with ESMTP id 3E6524000E for ; Tue, 19 Nov 2024 23:49:08 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ss76RQWl; spf=pass (imf01.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.172 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=1732059943; 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=Z5iheQODuTvu37VA0qmjd17458UC/wtiE8myRuiuf4A=; b=TIeSvRw86QnCuqOPMkIKHWcZae0TYWb+8oJW4zvC6H7e0A1yJcJszlbAqEszUTLsQG6WAL q/ZvriZ50YRKJTAhipxoFeayTFwXrq4QDMUOpEmNsjSWXYF/ZBYpGdkkFIxwn15cUVGh6s FQJ4t40Kp4qbvDJ9Mu46+Vzi4F6cAMg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ss76RQWl; spf=pass (imf01.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.172 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=1732059943; a=rsa-sha256; cv=none; b=fBMqsekqsA1vhyJEK9k3SvHTtzac41E0s7lxkcFH3gi3Pj0PaSqA9JOcDIUffiVcoci58Z t6YUXJg0Jr9blr9sXvIkX5j4UQ279FyKrCi8bf826smPkOFaD7Wc9rvFsuf1PsadpfzYcC GSePAsJ2rvy45VcPIRK/ahDNYWnErG4= Received: by mail-oi1-f172.google.com with SMTP id 5614622812f47-3e7a1f73dd6so324937b6e.1 for ; Tue, 19 Nov 2024 15:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1732060186; x=1732664986; 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=Z5iheQODuTvu37VA0qmjd17458UC/wtiE8myRuiuf4A=; b=Ss76RQWlfPyEjobX4mpcIx23/Gm/tkJ+0xaIVPrSQ60tCE2dZ8PyVOeaM4IntGSm1K Yt1C00Uu8VxVySSxQD9jT6FhAwr0Gnd1bZRyNQZHHNMr/JRgxkO6uEquZ9d82W27VZ7E b1JPN5h96jRXJuq++z4CrPW58+fW6HSrJ9G3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732060186; x=1732664986; 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=Z5iheQODuTvu37VA0qmjd17458UC/wtiE8myRuiuf4A=; b=S1q+Um8/GVcpgusUaH7wcJvlVLbRpDFbF4w4um4iJCyFWZCYAjDNK4L45UWZnUKmZi BsE4XQm1WaOKEgr6K7aMo1bS4pNaLPgLSdAedi0qJDj25V3NDcsUMI7USLOKdHUyETgu yARPgFUS5L9/ZdjOgDL8Q1zrYa8oox8wpL4YClgLj3aMLBsFYG1DMnoEdhPtSaSPI9L0 KzM+uHgWxL0NCdDYNfXcnIFgXwF/XEO2TlLpUJvp+VbzQvbKqxFgLWAnMs4DxiaitBDr nqIt04/R1wTDa+9ezNemlOGa1wnGOcOBhqe4EJyDEB9WL2FiQDajPQGg3cgxjr0WbuT4 TcSg== X-Forwarded-Encrypted: i=1; AJvYcCXNTTZjWCZKFUgShXex5IqbyLwmIheMeSg8SJ2Jed6gekivnNSz63d0B7kZXcy2C9p4/W/niZw8ww==@kvack.org X-Gm-Message-State: AOJu0YzWsVrh+1JMXLD5MUPzVsPKtyKBmSFgchXZM7Sg1+O8pGiAW9FI E1cIHIKVjGzhu0uIPkjXw6nA4Uusvlfi0pbv1aSTP2mBzXL5n3T+FSFvmNKcBERzD1FBlZQdFic zSvzF+FpRLNSZkLfZjNaQ55CvbzgP/OgSs7KK X-Gm-Gg: ASbGncu6IS1wRaJXni3Z/oKBfI37SXB6GAEFDs6dXiSqMU1gFI56dDSn98ThIioCN2o QDzESfK3+aLxHLUkKxSSls0BarejQgsu6hzOE9cXIyzcVM8L1PRbXPxWYGWpp X-Google-Smtp-Source: AGHT+IHD31QPNsbvkVhw5i8KrguJ2U7sdB7qpTdgMRr/hV5KyjzGtEb0LlJ573XxGhkwH8vOMD2IjByodRbLD/sUBtU= X-Received: by 2002:a05:6871:e417:b0:27b:b2e0:6af with SMTP id 586e51a60fabf-296d9b159dcmr180047fac.2.1732060186511; Tue, 19 Nov 2024 15:49:46 -0800 (PST) MIME-Version: 1.0 References: <20241113191602.3541870-1-jeffxu@google.com> <20241113191602.3541870-2-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Tue, 19 Nov 2024 15:49:35 -0800 Message-ID: Subject: Re: [PATCH v3 1/1] exec: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3E6524000E X-Stat-Signature: bu7nzhe8akpzegtx1a8u5864ctunkdue X-Rspam-User: X-HE-Tag: 1732060148-978720 X-HE-Meta: U2FsdGVkX1+6vz2G3FrIxUEHiCb6Ty8XmqOZ9SVIXDX+zuMhnoDAdQxZVOMimqlPjYN8rH47wLvTrZQarshZpQNkAZOlFBjudQ9kN9ztVJP7rmQW4rUBgxM8n24nukV3pNffsOxOIvyV0PiSMQmrnfGTG3FbgnYHIcuqWqlCWTM89bIrkNnWoR2S8ljTAJOZl1ceY5cPsRAOovhd1iduEzQG0NsRmvLPPxGTbB4Koz5ZXoRenHf/6Wu68GGbTy88Wf6bYqmJLcyrhih25ttY9aHIxVlcQQsKjwjZTbwRAfiePR4HC/jMsC9S/71Rw452tJNN4jWi3DjtvucwjkbEZiZ2DEHnmN4PCDhEEdGbLtXPetHSweSPIKYjyCuEu2uTO9udU2pD0rf/6nTlPOkLGzDDkO334GaCSE6p77tmGmxFtDo3/TpI6KGdC+76VwfZ6zot9WStvgMLhmxjWxqSxtjrtJNXOjZOBNDKtehOYhJ2W/meRaWLCN/R/nK+BET0zbkQbvPfnlSU0KHu9F0FMIZ4txwpCzBpLYNUXFrhjmYUHOvh+JFqgdhpUQ2RxTYCNlL2AqwK7XDVqFqwXlYQ9xmEwgCJ+R96DHJN9qaD+cBH9x049lk7NQzhpJ+aOdN2OFMkkluQ2D3DAugBOXspkBce45mSK2J9BNoEwaArFYGWESgSBGrGIdFcLccEyGa1uPBmY7Wctcov8UPrsBITqHx2II4+OJvlTZJPcbWtEYGx4mjqZKcQTNJfcSEL9G4Nz4mX0CrlRYQ/1qNNpPn+ZIRhglKjrdnEzlkHuHrCDQ+9eLxGrgrb0GVfofSTbiqazrthPNrrUZN/+wPyfr1DemcjWfqUFYDEt0/99/3LY2Xk9i23YakGVU6y7sjn6TrygOlMCV39FqXU1emsEReWhBwWP/YMejcJUTJu58WQZEuFU3jgTX/P5g5xtK8pD1CZHqD4t884oJ8xRWaj//D AB9W1FwW f+yuWFvFl6cqodr2o9PgRxrCOj7qLlLkIl7ZjSZSgTH0/zz+AJ+ORl8ltiFyUng2XRMmZUDTRvkRya2XGmSsB3TO6YmyVcLuoABglo8UjTc1WHetuT/yCdy1CxQW+gluMyAqR/QuD5nkAlJvd75Pn3q5SiuSVhIbEEGC3P68KTCnK8VlTHJ+S47yt/+MFovNQPUlSICi7rASzYHWpFtr4SzS0dAyyGl8YSpo6VuYtTepfaCKeS38TE3J8xD+DgutXMWiv2m0/e8M0EXySnOZPbtnUREhxLKDrX3uqVqcF1vCuQZJcW9CRNm0xHszjochh9W++ktzXDR7tgIAbqik7Yr464ft76ap4fzbYsDBZVa84Lvc= 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: Hi Lorenzo On Wed, Nov 13, 2024 at 12:47=E2=80=AFPM Lorenzo Stoakes wrote: > > I'd prefer not to move forward with this until we have confirmation that > adequate testing has been performed, given how invasive this change is, > even if behind a flag (unless we explicitly mention it is untested in the > Kconfig). > > We are touching arch-specific stuff with VDSO, VVAR, etc. so we need to b= e > cautious when we're in effect hooking an arch-specific function in mm. > > Other than that, the actual patch isn't too crazy overall. > > I think a sensible approach might be to only enable on known-good arches. > I responded to this in the other email where you raised the same point. > On Wed, Nov 13, 2024 at 07:16:02PM +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 [1]. 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. To address this, a kernel configuration option has > > been introduced to enable or disable this functionality. > > > > [1] Documentation/userspace-api/mseal.rst > > It'd be nice to explicitly refer to this in the docs, it's not quite urge= nt > though would be nice to be part of this series. > will update mseal.rst next version. > > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkR= kL-NrCZxYAyg@mail.gmail.com/ > > Signed-off-by: Jeff Xu > > --- > > .../admin-guide/kernel-parameters.txt | 10 +++++ > > arch/x86/entry/vsyscall/vsyscall_64.c | 9 ++++- > > include/linux/mm.h | 12 ++++++ > > mm/mmap.c | 10 +++++ > > mm/mseal.c | 39 +++++++++++++++++++ > > security/Kconfig | 11 ++++++ > > 6 files changed, 89 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Document= ation/admin-guide/kernel-parameters.txt > > index e7bfe1bde49e..469a65b3cf50 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -1538,6 +1538,16 @@ > > Permit 'security.evm' to be updated regardless of > > current integrity status. > > > > + exec.seal_system_mappings =3D [KNL] > > + Format: { no | yes } > > + Seal system mappings: vdso, vvar, sigpage, vsysca= ll, > > + uprobe. > > + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPIN= GS > > + - 'no': do not seal system mappings. > > + - 'yes': seal system mappings. > > + If not specified or invalid, default is the KCONF= IG value. > > + This option has no effect if CONFIG_64BIT=3Dn > > Or if CONFIG_CHECKPOINT_RESTORE is not set. Please update to reference th= is > also. > I will update this part. Liam has a similar comment. > > + > > early_page_ext [KNL,EARLY] Enforces page_ext initialization to ea= rlier > > stages so cover more early boot allocations. > > Please note that as side effect some optimization= s > > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsy= scall/vsyscall_64.c > > index 2fb7d53cf333..185553376f39 100644 > > --- a/arch/x86/entry/vsyscall/vsyscall_64.c > > +++ b/arch/x86/entry/vsyscall/vsyscall_64.c > > @@ -366,8 +366,13 @@ void __init map_vsyscall(void) > > set_vsyscall_pgtable_user_bits(swapper_pg_dir); > > } > > > > - if (vsyscall_mode =3D=3D XONLY) > > - vm_flags_init(&gate_vma, VM_EXEC); > > + if (vsyscall_mode =3D=3D XONLY) { > > + unsigned long vm_flags =3D VM_EXEC; > > + > > + vm_flags |=3D seal_system_mappings(); > > + > > + vm_flags_init(&gate_vma, vm_flags); > > Nit: remove weird whitespace above. Also might be worth adding a comment = as > to what we're doing here similar to the one in _install_special_mapping()= . > Done. > > + } > > > > BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) !=3D > > (unsigned long)VSYSCALL_ADDR); > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index df0a5eac66b7..f787d6c85cbb 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4238,4 +4238,16 @@ int arch_get_shadow_stack_status(struct task_str= uct *t, unsigned long __user *st > > int arch_set_shadow_stack_status(struct task_struct *t, unsigned long = status); > > int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long= status); > > > > +#ifdef CONFIG_64BIT > > +/* > > + * return VM_SEALED if seal system mapping is enabled. > > + */ > > +unsigned long seal_system_mappings(void); > > +#else > > +static inline unsigned long seal_system_mappings(void) > > +{ > > + return 0; > > +} > > +#endif > > + > > #endif /* _LINUX_MM_H */ > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 57fd5ab2abe7..bc694c555805 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2133,6 +2133,16 @@ struct vm_area_struct *_install_special_mapping( > > unsigned long addr, unsigned long len, > > unsigned long vm_flags, const struct vm_special_mapping *spec) > > { > > + /* > > + * At present, all mappings (vdso, vvar, sigpage, and uprobe) tha= t > > + * invoke the _install_special_mapping function can be sealed. > > + * Therefore, it is logical to call the seal_system_mappings_enab= led() > > + * function here. In the future, if this is not the case, i.e. if= certain > > + * mappings cannot be sealed, then it would be necessary to move = this > > + * check to the calling function. > > + */ > > Nice comment! > > > + vm_flags |=3D seal_system_mappings(); > > + > > return __install_special_mapping(mm, addr, len, vm_flags, (void *= )spec, > > &special_mapping_vmops); > > } > > diff --git a/mm/mseal.c b/mm/mseal.c > > index ece977bd21e1..0a9d1e9faa28 100644 > > --- a/mm/mseal.c > > +++ b/mm/mseal.c > > @@ -7,6 +7,7 @@ > > * Author: Jeff Xu > > */ > > > > +#include > > #include > > #include > > #include > > @@ -266,3 +267,41 @@ SYSCALL_DEFINE3(mseal, unsigned long, start, size_= t, len, unsigned long, > > { > > return do_mseal(start, len, flags); > > } > > + > > +/* > > + * Kernel cmdline overwrite for CONFIG_SEAL_SYSTEM_MAPPINGS > > + */ > > +enum seal_system_mappings_type { > > + SEAL_SYSTEM_MAPPINGS_DISABLED, > > + SEAL_SYSTEM_MAPPINGS_ENABLED > > +}; > > + > > +static enum seal_system_mappings_type seal_system_mappings_v __ro_afte= r_init =3D > > + IS_ENABLED(CONFIG_SEAL_SYSTEM_MAPPINGS) ? SEAL_SYSTEM_MAPPINGS_EN= ABLED : > > + SEAL_SYSTEM_MAPPINGS_DISABLED; > > + > > +static const struct constant_table value_table_sys_mapping[] __initcon= st =3D { > > + { "no", SEAL_SYSTEM_MAPPINGS_DISABLED}, > > + { "yes", SEAL_SYSTEM_MAPPINGS_ENABLED}, > > + { } > > +}; > > + > > +static int __init early_seal_system_mappings_override(char *buf) > > +{ > > + if (!buf) > > + return -EINVAL; > > + > > + seal_system_mappings_v =3D lookup_constant(value_table_sys_mappin= g, > > + buf, seal_system_mappings_v); > > + return 0; > > +} > > + > > +early_param("exec.seal_system_mappings", early_seal_system_mappings_ov= erride); > > + > > +unsigned long seal_system_mappings(void) > > +{ > > + if (seal_system_mappings_v =3D=3D SEAL_SYSTEM_MAPPINGS_ENABLED) > > + return VM_SEALED; > > + > > + return 0; > > +} > > diff --git a/security/Kconfig b/security/Kconfig > > index 28e685f53bd1..63b87a218943 100644 > > --- a/security/Kconfig > > +++ b/security/Kconfig > > @@ -51,6 +51,17 @@ config PROC_MEM_NO_FORCE > > > > endchoice > > > > +config SEAL_SYSTEM_MAPPINGS > > + bool "seal system mappings" > > + default n > > + depends on 64BIT > > + depends on !CHECKPOINT_RESTORE > > Would prefer to depend on actually tested architectures only. > I responded in the other email where you raised the same point. Thanks for reviewing -Jeff > > + help > > + Seal system mappings such as vdso, vvar, sigpage, vsyscall, upr= obes. > > + Note: CHECKPOINT_RESTORE might relocate vdso mapping during res= tore, > > + and remap will fail if the mapping is sealed, therefore > > + !CHECKPOINT_RESTORE is added as dependency. > > + > > config SECURITY > > bool "Enable different security models" > > depends on SYSFS > > -- > > 2.47.0.277.g8800431eea-goog > >