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 374ADC02183 for ; Fri, 17 Jan 2025 18:08:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD755280004; Fri, 17 Jan 2025 13:08:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8832280001; Fri, 17 Jan 2025 13:08:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92775280004; Fri, 17 Jan 2025 13:08:22 -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 73BC2280001 for ; Fri, 17 Jan 2025 13:08:22 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 207E0C096B for ; Fri, 17 Jan 2025 18:08:22 +0000 (UTC) X-FDA: 83017728444.26.4B69046 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 3255440015 for ; Fri, 17 Jan 2025 18:08:19 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IGdh2r0D; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.48 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=1737137300; 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=J+wrQ79XQ4ca9l/d+wViEvNToUhszDfun5nccti3Phg=; b=ObROA8WKmZGWinGHHhCzEIEtPUYc0A9sbogWQiALyG5lJKzfHAqq9qGSpVLC2dOwuf7sS0 dzbweDBhS9nVtKgdOs+u6Se2vDIPYbIwcSJEggLd9NQmFw+Orn89qzAo26YLRLvV+GXuvL dNfgN8WgJbnRmqhNh/CcXY1T5NUGTt8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737137300; a=rsa-sha256; cv=none; b=g5f1OAWdpVDDrG+RE7Tz6WjrGDkRQo+M8vDaPwFV+dnsrjyU6p/WzYkhvv4+n25Wlc+RMC eD3sewKIE6AP/hvVLtzDDdX0gtzipYV2lajnuPrs7znZQExIU1ftbniagPWtIgB6jr7vNF ZGSi0Lgsmjq0zEoxWIHwyfeEdpz6ZKI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IGdh2r0D; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.48 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-2a3c15b4630so435300fac.3 for ; Fri, 17 Jan 2025 10:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1737137299; x=1737742099; 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=J+wrQ79XQ4ca9l/d+wViEvNToUhszDfun5nccti3Phg=; b=IGdh2r0DLXUmC7hm3xmtgfYtbnRnuP5wNCLrFxS/HJn1jcfWDBKvtzim3En9X3vJ3F b/J4f1sYZRhXX/yQmb1b0auRCR3L8mYf9XBAXF4mPC4UZ/f/IWFCyvbR44JZi5cjl8uG ZEXfbq9FIASz+Qxz436+xTCYmDtVsoAkZI+Kw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737137299; x=1737742099; 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=J+wrQ79XQ4ca9l/d+wViEvNToUhszDfun5nccti3Phg=; b=vr7LGzxJWE+V8wRlRyRnYj3Gy/31X2jbP35tN6mg1QBzwx2q1nK+WGf2wTM7tE6kq0 f8u1ns4iUtxSSFdtMc5pX1rqeDptDMwq+j8jj+wf4cAfaVElCiK83eKRML2ZsIce9RpT gCu6XCtvqUyDMz2fdat1oZ76+EiwXSp4A3bp8S712KTKPk9kw8ES0oVL+iyOwN0y3SN2 VKfKQvLh+b8DEZBr3DuXEJ2CG6y4JB7qtMoEzhNDbHNT4csbJi/RqXjSCZ0fbPE1fAhc e4ANj3K0ET2xniNZubfpEHeqR2oJ1Fhm+txzonz0tKV313rXFSkaCM6LuGhFNUWKGPB3 Tc1w== X-Forwarded-Encrypted: i=1; AJvYcCUY5iA66xusqq63rZiKZA2PYTaXvdm6r/aAByG/nX5nRSp/Q7gw+GGfm+eiWCSUzW3BOsn/TFzJHQ==@kvack.org X-Gm-Message-State: AOJu0Yw9xRmGrM5Vj6jIu5aylwGw9oDqH5F1zThqZ08+5E6poFc/cA85 5tdAilZ5gQaaTQmoXzq+U2qQYRk5LHNHfXPwwUxBZJeWMYSfNOoi9VktwbnG6achw00kWJFFelf 1U0mBwoC9L7zpFdnLfI6QmQroO1SywfQMuBzu X-Gm-Gg: ASbGncvyg76bVMo7TcEAB9Kav+KWSMdAMxRHextQKxqX+yRdj68HyXc3K9QFaOwryvg DvZkNzbsOxjYtsuZ4S8MWmu9Xrkqljd8jdWbFoq+NZavAm9ZFm0p7g1W+J+wqhyPqcp/UfpQ= X-Google-Smtp-Source: AGHT+IFJ8fOBsLikiTC0W7GtLYaUpRBbqTiElAurGL67ZkxvsLPOiPeoJiRmQO4h1oncRiRsa3HsPioiMyw5bUnyoS8= X-Received: by 2002:a05:6870:71d3:b0:29e:43da:f5da with SMTP id 586e51a60fabf-2b1c0c55585mr889542fac.9.1737137299036; Fri, 17 Jan 2025 10:08:19 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> <202412171248.409B10D@keescook> <202501061647.6C8F34CB1A@keescook> <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> In-Reply-To: <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> From: Jeff Xu Date: Fri, 17 Jan 2025 10:08:07 -0800 X-Gm-Features: AbW1kvbcBFeiMkF_PxC9uDRDzx1jxsdsTHth5wMq9Ux1KdCyDdEQMsSqbOrSvzQ Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Lorenzo Stoakes Cc: Kees Cook , akpm@linux-foundation.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 , Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn , Benjamin Berg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: b3ctw7c4sxd9nyhnjuuocgw47wco5dau X-Rspamd-Queue-Id: 3255440015 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1737137299-822602 X-HE-Meta: U2FsdGVkX19qBJYLZvSW/9Jr4FbbpARe4mnB/0yYIgjecyHSzmSdXW223jZ0b8XF36YhzXGfNelh00uCSQ9ZqRK85LWrnwhPhWdcpWAZBWnrAbSRMQSAwabs0td1CN0nYYgquGYkppa1A8BoIuTddRqAzw9gwfD7jrucw+wL1A+cdviHtatiUq3IXqA5Bqm9Cc4yTmfENU6ObkJbp9FcyAH4sO5n63mNicdmUdMAIKk2NEaEGY1tSGW0Vz7/Vu4p5rru3qrtWfevyDjBZCzGWx/hKCRtAELhozYGD0jG5RIhMC7l26SnOYpey+PnqI0qUubhTPDRYCdD+t9sa0fsMrLx4iGql3UYt2rzcxGo2jQe7jP7AnYs0JTThPP0X6oia5mRKCxv+JYkvoVcAQ2qwtwP6N5DrmywsoZ1b7Ix0oIIs29okpF0GnggmQ4eyZ8KIgU58+JNvVVBptEUPyQ9w4YhUCebiwBgDQ9UWlqMU9xWkitxNsN+Oa0fPT03NWepQ2GjuvhgSEaqwqBSHTVBGNU8vOBlYYFV907HZyjG9QgTfYHujsyRKV2Q4M8s4qJpODxcuCGzAC8JJoWhf4Goo8p2vweJoZ8WCu+S091fIZgCLn+YCfrLjxXvDbRqf7o0vBpVgHwPPJZKExWXbJK2vDXBObgVu+uuYPbreF50uwk4UeufULAcqGMpPnDMSFQN3fvoUnSu8wG06dCCFYhVY+MA1jSwoPAyf1j0B+fbsZJi94vgEUJdBv/ojLXSLtsUSgw3oOfwc1AImTE+p43xpyUl38WP4Bdxzm5ZAsPYowF5shjbedLrttH7OCgy9RIwZsZBVu4ZR6COhVOs0coX8Ce1OmgNhQdK0/dz2Y6BpMpU1SVqVmeMRI1ghopYCQeWqjwCQzNXl9O4csbur8xxggdbb/7eRhNNzWCFNKPzY1at7Ms6J5+7b4uaPZ8oi9fsj+c0UbCuCHK/s74bLVO kK8VaJdC Hykh90WyoF1Qo7TvOdkjSkILrbqep7R2D5d5z7vDY8i1cJrZizXuj4MK3GY2eZxrR4siWja5B0UbiTNvsZW/8uWOGExl15clfCzxfLmm/8qXXum2RSjGEYpsNNb1jagdJY6YF52XWmKwaoFMSUsJQz4C0Yc/sAJXgnVeRX0dCvIUmiP3W9U+YINjlwzLwVFf/o4HGOIEo7U+PsAr/9xLlVrrY9ainBCSgvZ2pUUynZbqzhI4pDwZZ60N9MXm1Wchv3ZmVnJDOw8qrA65mZnYVZ1bkcENVwMgBaW9cUQmt1GzMh9KzG70dec1vzKni+wU6Eiioc8RB/Bz4ngw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.126214, 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 Thu, Jan 16, 2025 at 7:49=E2=80=AFAM Lorenzo Stoakes wrote: > > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote: > > Hi Lorenzo > > > > On Wed, Jan 15, 2025 at 11:46=E2=80=AFAM Lorenzo Stoakes > > wrote: > > > > > > Jeff, > > > > > > My name is Lorenzo, not Lorenze. > > > > > I apologize. > > No worries, sorry I realise it was probably a typo! But just in case you > didn't realise :P > > > > > > I've made it abundantly clear that this (NACKed) series cannot allow = the > > > kernel to be in a broken state even if a user sets flags to do so. > > > > > > This is because users might lack context to make this decision and > > > incorrectly do so, and now we ship a known-broken kernel. > > > > > > You are now suggesting disabling the !CRIU requirement. Which violate= s my > > > _requirements_ (not optional features). > > > > > Sure, I can add CRIU back. > > > > Are you fine with UML and gViso not working under this CONFIG ? > > UML/gViso doesn't use any KCONFIG like CRIU does. > > Yeah this is a concern, wouldn't we be able to catch UML with a flag? > > Apologies my fault for maybe not being totally up to date with this, but = what > exactly was the gViso (is it gVisor actually?) > It is a typo, should be gVisor. > > > > > You seem to be saying you're pushing an internal feature on upstream = and > > > only care about internal use cases, this is not how upstream works, a= s > > > Matthew alludes to. > > > > > > I have told you that my requirements are: > > > > > > 1. You cannot allow a user to set config or boot options to have a > > > broken kernel configuration. > > > > > Can you clarify on the definition of "broken kernel configuration": > > Anything that'd unexpected break userland in a way that would be entirely > unexpected. > > Especially so if there is a real disconnect between the person who is > enabling the feature and the program. > > For instance if a distro wants to be big on security, is (as is entirely > reasonable) concerned about an unsealed VDSO/VVAR/etc. being exploited, s= o > turns on the flag, but _doesn't realise_ or doesn't communicate (such a b= ig > problem and difficult actually for many distros/vendors) that this will > break certain programs - and then users do a kernel update, and *bang* > their whole system is broken. > > It's really this kind of scenario I'm worried about. > > This is the crux of it really. > Ok, thank you for clarifying. > > > > Do you consider "setting mseal kernel cmd line under 32 bit build" as b= roken ? > > If so, this problem is not solvable and I might just not try to solve > > it for the next version. > > Yeah, I really don't like the kernel cmd line thing, because of this risk > of disconnect - your justification for it is prima facie reasonable - the > distro didn't want to enable the thing by default but you want more > security - but then we have this issue with the possible disconnect betwe= en > 'hey here is security feature X' vs. 'security feature X breaks Y, Z + > alpha'. > Ok, the kernel cmd line won't be in the next version. The kernel cmd line feature exists as a supplementary to KCONFIG, and has its own user cases. However, this discussion can happen later when adding a kernel cmd line for this feature. > > > > If you just refer to a need to detect CRIU, in KCONFIG or/and kernel > > cmd line, this is solvable. > > > > > 2. You must provide evidence that the arches you claim work with this= , > > > actually do. > > > > > Sure > > See my reply to Kees as to what this comprises, sorry if I was not clear > previously. > > > > > > > You seem to have eliminated that from your summary as if the very thi= ng > > > that makes this series NACKed were not pertinent. > > > > > In my last email, I tried to cover all code-logic related comments, > > which is blocking me. > > I also mentioned I will address non-code related comments > > (threat-model/test etc), later. > > Ack. > > I felt that you hadn't hit on my fundamental objections and this was in > effect - a final analysis as to how you would be moving forward with v5 - > but apologies if you did intend to separately discuss them. > > > > > > if you do not address these correctly, I will simply have to reject y= our v5 > > > too and it'll waste everybody's time. I _genuinely_ don't want to hav= e to > > > do this. > > > > > > Any solution MUST fulfil these requirements. I also want to see v5 as= an > > > RFC honestly at this stage, since it seems we are VERY MUCH in a disc= ussion > > > phase rather than a patch phase at this time. > > > > > Sure. > > To be clear - if the series is viable, I want to see it merged. And to > further clarify - a simpler, smaller version of this that explicitly > disallows breakage in config options suffices (though we must clarify the > gVisor + UML things). > > If I just wanted to reject this outright, I'd tell you :) (I don't). > > I just need to feel vaguely less anxious about breaking things! :) > > > > > > I really want to help you improve mseal and get things upstream, but = I > > > can't ignore my duty to ensure that the kernel remains stable and we = don't > > > hand kernel users (overly huge) footguns. I hate to be negative, but = this > > > is why I am pushing back so much here. > > > > > Thanks. You can help me by answering my questions, and clarify your > > requirements. I appreciate your time to make this feature useful. > > Sure, hopefully I have done so, do follow up if anything was unclear. > > > > > Please take note that the security feature often takes away > > capabilities. Sometimes it is impossible to meet security, usability > > or performance goals simultaneously. I'm trying my best to get all > > aspected satisfied. > > Ack, and I realise it's often a difficult trade-off. I just worry about > compounding complexity in consequences of kernel configuration vs. userla= nd > stuff + the disconnect between the two. > Understood, thanks for explaining. I value feedback to make the feature useful/robust. -Jeff > > > > -Jeff > > > > > Thanks! > > Cheers, Lorenzo