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 2DF9BC021B2 for ; Tue, 25 Feb 2025 14:00:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 995906B0082; Tue, 25 Feb 2025 09:00:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9456D6B0085; Tue, 25 Feb 2025 09:00:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80D416B0088; Tue, 25 Feb 2025 09:00:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 635FC6B0082 for ; Tue, 25 Feb 2025 09:00:10 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E857AC16F2 for ; Tue, 25 Feb 2025 14:00:09 +0000 (UTC) X-FDA: 83158626138.04.496A16E Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) by imf09.hostedemail.com (Postfix) with ESMTP id 2AF8914001C for ; Tue, 25 Feb 2025 14:00:07 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=sipsolutions.net header.s=mail header.b=jrlivbiN; dmarc=pass (policy=none) header.from=sipsolutions.net; spf=pass (imf09.hostedemail.com: domain of johannes@sipsolutions.net designates 168.119.38.16 as permitted sender) smtp.mailfrom=johannes@sipsolutions.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740492008; a=rsa-sha256; cv=none; b=KtjuINqvTfApEB8eq19WdHIpOxHLbaziH5pWGxomMd0nYUi9ReTt3oaePK4lu7fVP7GXLc OyWUpb7s9oSDG27zEsG3keiSs8OesFYpjis1L40YJFTkBSoSCBfmzg2Vi6lzziCNaJG03a U1mutN+OxT18GywBgF8tfx7yukJ/yJo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=sipsolutions.net header.s=mail header.b=jrlivbiN; dmarc=pass (policy=none) header.from=sipsolutions.net; spf=pass (imf09.hostedemail.com: domain of johannes@sipsolutions.net designates 168.119.38.16 as permitted sender) smtp.mailfrom=johannes@sipsolutions.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740492008; 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=BhCL6BrxT5nxXUnjaAAPt59Z+GHxn/wDdR1kkVg1Rm4=; b=pHG622P2ZvvX4+zxf09CUIk/sbgwhyVXNszN073Z3+JImm/Pvx2KjbAooLWKtpoHfMtVQD 4DkM+19GV+9vWEBGSvjDeBD1Uw5U/44H7L3+P9avJT8SsbZArge3pNAFpzSv7eBcK1mt9d tqqIKXUwp/jnLYzGcYNaaD1SnLXQmJ8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=BhCL6BrxT5nxXUnjaAAPt59Z+GHxn/wDdR1kkVg1Rm4=; t=1740492008; x=1741701608; b=jrlivbiNBCmULClKf5ki57Hsyb07YilddiYtTaHOKsUIRZ2 N5TtYGq9tg+nHags8mCENvvuAd/DlMI1IBa2a9IJZ/r14SPRIDlXxGnyz6RSDZKEIWafHp5hwIHUe rgzkCMy3pBGPkEURgseoOfIx/S+r6JdriSz2qlPSIu5L2EnzFend5qgWs0GGN7bHs0bf2OXf0+WIl IldE2aLRtoekVIfcJVcNAI/wjsP1odaj6IISNkrEix2RTWMHPCzkd1hNLrdlj+/HDKqjpZ0xW8p6x 1nfcFoSnBrK9Iz7+ZRo9z4m2Yzsq8DF09fS0jEY66rZ6RHEQu7o6q+c7mMuTe5aw==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98) (envelope-from ) id 1tmvTB-00000009va0-3KcC; Tue, 25 Feb 2025 14:59:34 +0100 Message-ID: <47a3d0c82e716c1838d76d079c89d230d2d1fe19.camel@sipsolutions.net> Subject: Re: [PATCH v7 5/7] mseal, system mappings: enable uml architecture From: Johannes Berg To: Lorenzo Stoakes , Benjamin Berg Cc: "jeffxu@chromium.org" , "Jason@zx2c4.com" , "adobriyan@gmail.com" , "deller@gmx.de" , "gerg@kernel.org" , "anna-maria@linutronix.de" , "davem@davemloft.net" , "avagin@gmail.com" , "mhocko@suse.com" , "enh@google.com" , "thomas.weissschuh@linutronix.de" , "hch@lst.de" , "hca@linux.ibm.com" , "peterz@infradead.org" , "adhemerval.zanella@linaro.org" , "linux-kernel@vger.kernel.org" , "ojeda@kernel.org" , "jannh@google.com" , "f.fainelli@gmail.com" , "sroettger@google.com" , "ardb@google.com" , "jorgelo@chromium.org" , "rdunlap@infradead.org" , "mark.rutland@arm.com" , "Liam.Howlett@oracle.com" , "vbabka@suse.cz" , "mpe@ellerman.id.au" , "oleg@redhat.com" , "willy@infradead.org" , "keescook@chromium.org" , "peterx@redhat.com" , "mike.rapoport@gmail.com" , "mingo@kernel.org" , "rientjes@google.com" , "groeck@chromium.org" , "linus.walleij@linaro.org" , "pedro.falcato@gmail.com" , "ardb@kernel.org" , "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "linux-mm@kvack.org" , "linux-hardening@vger.kernel.org" , "torvalds@linux-foundation.org" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "aleksandr.mikhalitsyn@canonical.com" Date: Tue, 25 Feb 2025 14:59:32 +0100 In-Reply-To: <19e81e87-7430-4e23-ac67-dbb987496dd4@lucifer.local> References: <20250224225246.3712295-1-jeffxu@google.com> <20250224225246.3712295-6-jeffxu@google.com> <96ebddf3fe31353c89f6a4680eaeb2793c25cd09.camel@intel.com> <7e91bea34552472757a8eec425d1d10643ca584b.camel@sipsolutions.net> <19e81e87-7430-4e23-ac67-dbb987496dd4@lucifer.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 X-malware-bazaar: not-scanned X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2AF8914001C X-Stat-Signature: n1jxiwz1h57on7phdi9cz5n7f7mmn8g4 X-Rspam-User: X-HE-Tag: 1740492007-166544 X-HE-Meta: U2FsdGVkX18gU2d6KyciagXKEsx87QKqsqrSBz0cAY3ZLKdw7nPR9TQ2fijDarir8wOFiS3zQS3W9SazcJZyFluYVHdxrZCTSBlarYHymkTQzNtmF0yHb2mFP+4VwvEzYq/yvIDly7Ao/jJhAV94hHb2Gmum4S9VMlTOzj1JWB7t5cVo6+oWMjCw17s12lljRcnvEemHfiUCH+57BxUG51EJnDQ5zpPUzjTuiOOJgIoOXj9cUc8l46QkI3ctgeGg4kLtAcDk1y1bjtz+OZupPFv8kX/RTTy+k1nBDZJ4XxKs2nUV29XP3F+ASuRf4HKdLbPvH2D8GPRisFM9zhKEA+FB1lhudE8IcOoj6ysrAw1MF+7KW3amaSFxlZFXWg00PyMlfZ1+IoZHmTXFaqnsCE5JZ+YJy0gBzVvhhAHv1lBPgEwwZCyGdyeBZf9ovQKARBckGDC3WoJ5kJA+cdppi22QaLFNqy0bUn7gdu9Go6CgZp8dRcH/VyOALovZ9azrQ4Z7KmNX4UhoMoNQqsVXcPpfFn8q/wrbklw8ZrqvTVdEiiDmQP3CmMdUdFxxtySFG+2J/zCikYG4CyPB9JS+wH6DNmgEgnCnxa4a80ViHk0lundxbMTBqsScm6mkLFYRI1W+XAB4B9n8QLZjyev70oTOzrv7DcmhQGJePdHJMF5ae5r0QwQ00IGv9GqsYLg+1dvhC2QztZWD3SACAtAZp9akfXzpTKuU8vxD6uSBXioxsVd3xTM44Gyacgrov/h882/19v+YWXR2+HUbGJ+UPOYJz4cQSibzcOUTX4s8ja2dNECwhuneqQb1ND/fZhhDQe+FmA03TM8EVwvRfySSWP3ZCrkxEkIELlS4LQjGKTzSn/kDRVoLSlzm+4CfgRNpMDYoV4p6kbhVXsSquGWQRRXochSv2uWghQnvLFGKaCFFB58l1SkPMr6PVIRymMCJdVehqLdNIAKwHOtRQL0 IsKLCa0Q XIagc21sJK/VUeyJD8hHTLPlyaf+ipZ2An1smYC/gK7xLAHSxYbeRtins12V6FlAARNjPH4lC8QwILrqD0aUp1IznoSJz+Nv4UHuf9k2cgRzG0jmciSnL8+O1N4Z06raLj3UjrRydgDfvY9hZajfhN0fWNnfWFRG/2wb/m9C5bcb9s45BD2Cytc4uSf3Zwlh9zZjKvq4uuUXswuNsz8RmL70UnXwzDScE3MC9E9BUWY8P8Kxf8HzmgbkznDKtOO0FgrXEXOKjs9iigpULHkSNqYIXUzkknja9PZvdLAbyVO0D3LQhAPsJNOBdJ83wujTUnrhQBYKXHPrGnBfUm1V3iITR3W6AF2JmZbnt 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, 2025-02-25 at 13:41 +0000, Lorenzo Stoakes wrote: > > I figured it is not a lot of churn and there isn't really any cost to > > enabling the feature. > >=20 > > That said, the only possible real-life use case I can see is doing MM > > subsystem testing using UML. We certainly do not need the feature to > > run our UML based wireless stack and driver tests. >=20 > OK ack - my concern is users getting confused about this ironic host > vs. client thing, must disable the security feature in the _actual kernel= _ > to enable it in the client. Well, s/to enable it in the client/to run the client/, I guess. I'm still a bit disappointed in the whole thing anyway - if this does get enabled in e.g. ChromeOS (as it looks like), then it'll mean that gvisor/rr/UML will never run on chromebooks, which ... I mean yeah who's going to do that, so it's more of a purist disappointment I guess. Can't run kunit on a chromebook then, for example. This looks much different for more general purpose distros too. I also don't really want to reopen a discussion that was probably had before, but I did wonder now what the security downsides of having an opt-out, e.g. a new ELF property, for skipping the sealings would be. Perhaps, depending on the impact, even making that mean "no system mappings at all", at least for UML I believe they're not needed in the first place. > I'm not sure this is really worth it? >=20 > I mean I agree this isn't a _huge_ amount added here and I don't want to = be > difficult - Jeff, Kees are you really keen on having this? Do you have > specific use cases in mind or was this just a 'because we can':>) There's always kunit that can run with UML, but I don't see tests being added for this feature, in fact the only thing here is _disabling_ a test. Maybe it should come with tests and then it'd be more interesting ;-) The commit says "Testing passes on UML" but I'm not sure I see what testing that might have been, per the cover letter Benjamin did that? > I guess if intent is to slowly add architectures, it's not totally insane > since we kinda know this one is ok so if that's what it is, probably won'= t > oppose it _too_ badly. I think it still makes _some_ sense to have it for the testing aspect, but perhaps might then make sense to split it out of the series to avoid all the confusion and submit it to UML separately later? Or just leave it since you can always test with qemu. johannes