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 42688E69E8C for ; Mon, 2 Dec 2024 19:58:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9858E6B007B; Mon, 2 Dec 2024 14:58:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9352A6B0083; Mon, 2 Dec 2024 14:58:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D5BE6B0085; Mon, 2 Dec 2024 14:58:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5E2346B007B for ; Mon, 2 Dec 2024 14:58:14 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EF83D4030E for ; Mon, 2 Dec 2024 19:58:13 +0000 (UTC) X-FDA: 82851080130.26.3E7AFB2 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 3A0782000D for ; Mon, 2 Dec 2024 19:57:58 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="XzmYr/zr"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.53 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733169486; a=rsa-sha256; cv=none; b=N1o/qR6wWvxVfqd115t9l58YNzFQAqgS3H9wae3HO4TYvWk2BK/lYVUPo30a6MBHalmicn 3l/HaQ2SCeYblL8narvVj9Yic7OUQymZCfDRRLGOuu6z3NY2fVELDaeiyEO8nbenOOa1gL DEibRW9crLa9N6cXBfAF1EMOLiTIvxY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="XzmYr/zr"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.53 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=1733169486; 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=pDO6IZF0SAS4D/s22IkqfUjLK72pbPVPekVRwv7GXjk=; b=sDn9AhSZNMQ5/YR4f+xIbxdtz3ciuPl1G+O6uyoDWHsY7lBDgMP/O648tQKLLd8+gWTMir uV+NYmQs6fjNcRT4RlRm4JKEl4fp8UXG7MypE7kCviP2ax5ZT6cAQEZ3xZgZprX4wx+g1w 5wS0zQWhF0iPGk8w5j15EvHRCxefknE= Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-71d4d6f1825so554291a34.2 for ; Mon, 02 Dec 2024 11:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1733169491; x=1733774291; 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=pDO6IZF0SAS4D/s22IkqfUjLK72pbPVPekVRwv7GXjk=; b=XzmYr/zr+lLeCDntUeS6lRlMB9W87r8QJX80KGsYEj1S1fCvOCPC+dl//KV30pAsK2 +DfyP94Y2eVkXfRHDW4KiHutFDCII8G1nOIzqJkOwRGn09dFhNo4np/tbjb2rd8rOh2b cmSdIGR4YRKF0QX5s/VU71nJoRFNUkJzFlI8A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733169491; x=1733774291; 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=pDO6IZF0SAS4D/s22IkqfUjLK72pbPVPekVRwv7GXjk=; b=fUqmMptwCVzayJ0CzPt+oK7wniErBM7qBjwpe32G86g9EkMzR7CMQtrDFjiw6mdKWk xR4DMO3Ru6vggeNQqWf28xI8oC2/6RdttfehFsvBQ47O4Zk1V8pXY/gxk5WiH1tio9Mu +hrNBkwcIWatNgbvTYwq0cYogRIXoEYxEhxkFh4QIv8SSdBBvWyC2VnIfQKEoYK16RoB OfHdVrXhjDvmdniIG9ZRy3iIbu39yCf4ZnMUI6kg4iSfKFKlTCzd+jyRhcBN4MfHyVwP 0gdokeFuRE70K96nnljV3M8Sl4RMyY8m+hXxcKY8a21jg5muHBMWeiuN27bE7dbrlUT6 7IwA== X-Forwarded-Encrypted: i=1; AJvYcCXj1OU/xvvec84NatjZcmC5v32x3eoN5idcnPBnkSNsPRSj3qp6pzMTrB377/thOUJcWTfnz7iDjw==@kvack.org X-Gm-Message-State: AOJu0YwM28pUlCIf1lZGUzo/dDKwS5a0phlQjbxaay/o7Wqu05OOPFWf jq3nusDupQz/qqs1Nv4B4/qX+VJwoZ9JB7gx/3z75kthMjdd3PISjdH1sfYp2WeqMdAkdgJQ/mD 5mfQfaJHjDDgFbb2DcY0p9oaoBR3WJV1BUDSU X-Gm-Gg: ASbGnctTtUli14jxtxMqvNSkiN/zKopl7DFida/liaqdd6iCQsYnhJbU5fHZh0jV/UI 8wLPAz6QpUkjgwSlyyeM4FIo1A+6p3vG9ntxnLM85K0qjeUlJtCtC9IScDUmv X-Google-Smtp-Source: AGHT+IGl9S0cXUdxwqv/0H2bzvcmZTd1ty7QqvW+00DZx9eAOiGMi+fu/EM5EbCePNS3yghVEdCoOFfKaX1tiqKTfuw= X-Received: by 2002:a05:6830:6f0e:b0:71a:20da:f323 with SMTP id 46e09a7af769-71d65cef4a9mr5426443a34.4.1733169491035; Mon, 02 Dec 2024 11:58:11 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Mon, 2 Dec 2024 11:57:58 -0800 Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Matthew Wilcox 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 , Lorenzo Stoakes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3A0782000D X-Stat-Signature: fbix1mqx36ezzd8fazj39g9odcczp1kf X-HE-Tag: 1733169478-928283 X-HE-Meta: U2FsdGVkX1+ui1Z4ZEHDszOlE5QDOcH+YKc3URhpTe1nz8Zid2barljPHQGFuTSZC8NeRPXfmIihYk7ZsUI7TdaVP1CWjLX2ALiBemCNbQDluEEkbOYKULn7szNzL10ucTcRVIrAy3dzfth2W8CvQhC4BXbuF9BxSxt92QoI4VAe+GuIXS9VqEG0Egn3mey1gSdKbGN2dOgELHEegj5La5CMN7TVHUxDOXnPmA9nw1P6tMKjNWOtuA80hvRoe12gmGv5fTROBQvm2R/5MjBeFXi8QAATrpgCCHL5m9PLJLLwEd06nrGrvYMJ6Jgy8uHmzwll4TCCLfUG4pkxuDWPLa0cUxiS6+ON0a8qOlGS/OsKTqVNgFk+Exeq6erFDE8RK8VHV1yZxijXn5P9dfls4VD7ZfGW+UZgHqVWD4xW0RQ1V6zDnhA5xLwIL7A+f5Ub/T1VICGZ3lW2MiYIovGJu7PXK0jxqhiUTS8CQnr9Y0tm45/dDCYqhrdNvOkBnzQVq9hPS+o2iReBZXVBE0PpkfMJZfW8cOPfbX9HgfISt8lpncJVq89MhN0nS/mhZ9L+LAM3jejbB7/n2SzHBIntJ5V0iuVlpweE01FNGuhSwhc+X12GZaBgTyvKOw16m18sCNMAvtGoTSEK7AvGsgwq27H6ClAZSq/KyhC3rrkozYNJ5hxWYEy5PXIVkiA4sp/KTpdzVHRSej0KsiHNoquX462W9aSsWXub3AzPY40o2QhzvLF+ufB93AiRXPhsvS1+gWKWOerrOtXir+/LRQ8mk/rgGs0fjwx9+XEssOX452SQXzoSSiaL9H05tB+EqXtmOxr1L/9ebL4u59tuqqPKLmKDhfTWbiOd1F2Ut9nT8DO0qNOc4+4jY0ai+xvI1TRNF/w+BiqniumGO/Pw3EIlELIuKtDwmOMd9JBEfXBx0+w0CXtx02aYV5fHl/zLsHyVtVv7pNv6DsgptBsQdV5 JmeUoGd4 yg7a0MlQJ5Gyr9TeEnGxF3/jCnAs8zZWBpSMonhWtPu9/kcq+nDZHFjYDtkm5yJzaI9XpJGJPSaDkc7osg4eMR2BsTQ5fiG14DseqIW6VXYw4SakSMBtaZCL0OQ89Q833acdxAfYUVmp35EFMnCASfWLV7qyR7YWcLclfcHhzxi+6LHPSY+W9+5waib0otbjhTqvfG2jlGLob5haMM19iBwvLFVbgCCT22Il3TAdFgmm04CN//CVRAo5Sh098T5Xt8Q+c7StYzlxGvHvFvTGWgFp8JllFmN6crsMvDZ45yAiEghOdt/7keT8r3vxvJ+VESyLBMrC64ZaAZM3eeN5gqJdz3ecBpeQ3QIMNw2vWXHXXIryTf2fuExVk1cdhpoo1D0/awKAwjuG9AgN2AhSXupprka5LqEiVFvCJnaptTgsI0fSUHxH5RPzk3w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, 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, Dec 2, 2024 at 9:22=E2=80=AFAM Jeff Xu wrote: > > On Mon, Nov 25, 2024 at 12:40=E2=80=AFPM Matthew Wilcox wrote: > > > > On Mon, Nov 25, 2024 at 08:20:21PM +0000, jeffxu@chromium.org wrote: > > > +/* > > > + * Kernel cmdline override 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_af= ter_init =3D > > > + IS_ENABLED(CONFIG_SEAL_SYSTEM_MAPPINGS) ? SEAL_SYSTEM_MAPPINGS_= ENABLED : > > > + SEAL_SYSTEM_MAPPINGS_DISABLED; > > > + > > > +static const struct constant_table value_table_sys_mapping[] __initc= onst =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_mapp= ing, > > > + buf, seal_system_mappings_v); > > > + return 0; > > > +} > > > + > > > +early_param("exec.seal_system_mappings", early_seal_system_mappings_= override); > > > > Are you paid by the line? > > This all seems ridiculously overcomplicated. > > Look at (first example I found) kgdbwait: > > > The example you provided doesn't seem to support the kernel cmd-line ? > > > static int __init opt_kgdb_wait(char *str) > > { > > kgdb_break_asap =3D 1; > > > > kdb_init(KDB_INIT_EARLY); > > if (kgdb_io_module_registered && > > IS_ENABLED(CONFIG_ARCH_HAS_EARLY_DEBUG)) > > kgdb_initial_breakpoint(); > > > > return 0; > > } > > early_param("kgdbwait", opt_kgdb_wait); > > > There is an existing pattern of supporting kernel cmd line + KCONFIG > which I followed [1], > IMO, this fits this user-case really well, if you have a better > example, I'm happy to look. > > [1] https://lore.kernel.org/lkml/20240802080225.89408-1-adrian.ratiu@coll= abora.com/ > Sorry, I miss-understood the code. This code also uses the kernel cmd line, it is just not using keyword=3Dyes/no pattern, but checking the existence of "keyword" in the kernel cmd line. Current pattern allows values beyond "yes"/"no", so if we ever need extension (e.g. a new system mapping type, or pre-process control), we have flexibility to do so. On second thought, that might be over-thinking, I will switch to this (simpler) pattern in the next version. Thanks > > I don't understand why you've created a new 'exec' namespace, and why > > this feature fits in 'exec'. That seems like an implementation detail. > > I'd lose the "exec." prefix. > > I would prefer some prefix to group these types of features. > vdso/vvar are sealed during the execve() call, so I choose "exec". > The next work I'm planning is sealing the NX stack, it would start > with the same prefix. > > If exec is not an intuitive prefix, I'm also happy with "process." prefi= x. > > Thanks for reviewing > > -Jeff