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 A300DD60CF4 for ; Mon, 18 Nov 2024 22:24:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0067D6B0085; Mon, 18 Nov 2024 17:24:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF6946B008A; Mon, 18 Nov 2024 17:24:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBE076B008C; Mon, 18 Nov 2024 17:24:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BEA536B0085 for ; Mon, 18 Nov 2024 17:24:42 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 492DEA06AA for ; Mon, 18 Nov 2024 22:24:42 +0000 (UTC) X-FDA: 82800644472.06.6E11BE6 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf03.hostedemail.com (Postfix) with ESMTP id A935B20003 for ; Mon, 18 Nov 2024 22:24:17 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=F94uyxY1; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731968497; a=rsa-sha256; cv=none; b=e5w1zvqWzGY1IAgDjZSAOCrQpyGTumu9lnPEAaXvGFVhK8KL5wjc4t/0U4sOmBRzWRNBes ygPV3+uhmvEI588AkCCPxp8UrVrYicLtpzWmAeZvDCicv/otn19GZAh4KRgny2je0kSom2 TiXy1PJesShYCLVwbL11oRfcUlFcpDE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=F94uyxY1; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731968497; 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=mr6iDGZX6WZlOIa/AqtWy4H1dbsMF9ugeMcnS6HxJNE=; b=E6pvTaqDg+kxmGnX3k1cCSSU09b5JPOPRbxlwU06/CefeYsRWKeQUqh7seA02uNYnwS1EB 8UEWywqPgeUyVQyQRsziI9z8ydhPK4DuE86Axftzk/pgEJoz5s8wGzqlAY7MoXngsXRo7k 42BeMMg78TqEm3lan0uWbt45uiR05sE= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-46097806aaeso19437091cf.2 for ; Mon, 18 Nov 2024 14:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1731968679; x=1732573479; 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=mr6iDGZX6WZlOIa/AqtWy4H1dbsMF9ugeMcnS6HxJNE=; b=F94uyxY1pFQ1gPq/hJTTXTcnp6QxoqSkmNg+91vf9t/ik4466u1dWqebT6kFgzH6SW GC3nnwDml1/62RiHk3IW0XAaWUOqJUrD3hUgmLBbbSEdpFu2HthCHewcILxcnz2FYmmF LPxlYD/kv24MMYeNDGPh3IKwhlAF7cTLU+Vrf0kCsFFbDVahUUwpFy7iz8exjqt6+HKS 6lzBoU7TYGd3qWgDMfQQm6XQTotT6je1kSjcX6jS2mYTbWHPk4zM9gV4TFhcDpo4G3DJ 9AybULzuoPG0mgmXjm445emRRH1NyjeT8hK/cgLmv1SOWOaL6bWBfYT5SSdRJfV6x9ZR 1Qlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731968679; x=1732573479; 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=mr6iDGZX6WZlOIa/AqtWy4H1dbsMF9ugeMcnS6HxJNE=; b=I5sNosg4PDg7sWDJOm/oPTMJWGFVsTR1XCmfYFD2UWEb87RFmQ04TMsd8AgKMgkTPl LowWsbnc+pnSQ+lnyG8IVPEXVWqLqV5rMwKxPyBG42pkw58AKr9BQF5bVkwERy8ULk7D avK8dFQnk4JXJnydVB2tyr86fLUf2v93JOO96z6WASUKMC29c3jjDuzAkdZJpCdLApu/ zDp7Scb9JO6zE1N61ffkE25lBrr2taCIlhi0rtQkBpDKQ92jBFARt2RdwKUPfYcIfLps lIGDOgaYevN2IEKMJAyfLrN41M9cAzcbgpXSgfIpkgohh9cXj1TAY6UK0PckTfMpay9W 5mmA== X-Forwarded-Encrypted: i=1; AJvYcCUNUbAfS8ubtuqQ0gz7rkTejMRbBX+CfCRafHdXaKEk8E+x7/eaoqwb4u+hpvNQR0sJap1ZZ0RTOg==@kvack.org X-Gm-Message-State: AOJu0YytGHPKaY6nd9/MH0OM2xDuxmJRVhNmqgiiTPwjt4XQPDbk0cxo IJJPPlGxPpCbJnPfcMqbFtqE6hUaLeAmxjyHBem4q+mvvylJqJ2dfci/LH03nfTnJ39+nBY+w48 geRHoYQE2bHfEy4dL9NUF5Fwi3Z+rHcapxtsC2Q== X-Google-Smtp-Source: AGHT+IFJn12BEIzoEKgSqnP8cIUM9l+AVMCmmrovlugeE4ncddPOm9spXZtngGYQPZw7li3y2om6vXnU1SKoOL9vTX0= X-Received: by 2002:ac8:45c8:0:b0:463:788e:7912 with SMTP id d75a77b69052e-463788e81b9mr128943351cf.56.1731968679432; Mon, 18 Nov 2024 14:24:39 -0800 (PST) MIME-Version: 1.0 References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Mon, 18 Nov 2024 17:24:02 -0500 Message-ID: Subject: Re: [RFCv1 0/6] Page Detective To: Jann Horn Cc: Lorenzo Stoakes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, akpm@linux-foundation.org, corbet@lwn.net, derek.kiernan@amd.com, dragan.cvetic@amd.com, arnd@arndb.de, gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, tj@kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, Liam.Howlett@oracle.com, vbabka@suse.cz, shuah@kernel.org, vegard.nossum@oracle.com, vattunuru@marvell.com, schalla@marvell.com, david@redhat.com, willy@infradead.org, osalvador@suse.de, usama.anjum@collabora.com, andrii@kernel.org, ryan.roberts@arm.com, peterx@redhat.com, oleg@redhat.com, tandersen@netflix.com, rientjes@google.com, gthelen@google.com, linux-hardening@vger.kernel.org, Kernel Hardening Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: hfwmkiawhn1iyuww3ymtsfok5d8e56iy X-Rspamd-Queue-Id: A935B20003 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731968657-267208 X-HE-Meta: U2FsdGVkX19rDTya6210/YAN8aqPyBqI+A0rI5VWRcSBTpWOahCZ135RhMZQKa/loGEL2zZq1vh7NtLwMW8Beayb6iAo+skqcApSYEvYrSxWLCZK0hnNuwvL34nbYCyFQgoAOEysWXKrBtMcTWs14b1Q0JyzHsm+JM5f84DcUir1pRGi+Tz+hSR3QwUQoBdWbx/oGRDvVBM5L7n5BJucihC+a+BE+GPritEZtRWa8rWVamc1Ci6RrKRYBZvN9bbBVQ568reJUmw6baXWezLOtZuNIJ/vyS7VnES5gl6Wvl7LurMwaSgRmGhi7PGoEVL65zm2DH7VmOTJ57wnq1bmq3rh0VxwTSFCXReLamYCDESyH+Lp9uXBtHeesNqq+iiV+K1IFdYfofL+boGRfiltcfVo86fKVu4MPAzWFlpaK/EipR/7NyR8LRnFoXalPLIFn+PCYGCQKTOo4FqAeLjj+61Ps2aRnJfJ9vysEfr+MeshLqdjeNVHE4ewkvvcMZtGiGFM3GhsccVI7xyGEc4J3GQWXIhyGoa0Z+aaLewXbp2hcdCC+arxl2w/84I9D9r52MgOiqE8NUXtEodrRBAFCeJAWj+7q0TGlQq+6zke7SKxSXM1PraBb4oFrDhZ9QxOmshVZlKRCngp4X42uRO2WQ7ZYoYHpAOqU8iT8yxP5YGR3eICcS6Khq2HZD36E1hOc7k0E1UHwQDUGe0MreAebz9nVR4Ap/bLILpf3HLwHkE4oQvPBNtX+INr98qmhD2yuVynceEVrhJasqEw/SU3tAvivCKVgekHgkjvjBqczl9AhlnXE/nyseC/PK56VWQYb1gw0PWoArepjEkLYr0CtlqEGuD8qEAxsMsNUhaZXH7wdqG21SjfdzmFGlbbM6SbhbMfmF202jwSyzMqE/Z3yILPRsMbzz9pxwByVZWTCqoDIRJ3W5d4zQ8PC/ELvvDAAxcQuce87Cna5ICjXPe HHoUE7GC nyqeU0xGMXZ/Ij94XlrtdHwMFN18ffLNKUnfCmDETrwbZIs0v+Ry/IVVlxzS24uhguFIIkRH5DOlIB+t55NWlm9LV2oP9b96Hi2nTViE0/D8M5HagLo3R1lk297hpMq97yR1y9KzQ0SYl+kOR0H6MDNoEEHB+OWIsaLFNVTkB4aEUzZhgKJFvut/3egxdqjBf5wMr+Ne8CFM3tW1p0s01O3FMKV+zqNMUBdyvbyz4cutMCpGmlZaIAmvBH18NP+vbtMdj4RKjUpKxo3YBCqPt2S2eLGy9y3VW35OHg/YEEnlN+L8= 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 Mon, Nov 18, 2024 at 7:54=E2=80=AFAM Jann Horn wrote: > > On Mon, Nov 18, 2024 at 12:17=E2=80=AFPM Lorenzo Stoakes > wrote: > > On Sat, Nov 16, 2024 at 05:59:16PM +0000, Pasha Tatashin wrote: > > > It operates through the Linux debugfs interface, with two files: "vir= t" > > > and "phys". > > > > > > The "virt" file takes a virtual address and PID and outputs informati= on > > > about the corresponding page. > > > > > > The "phys" file takes a physical address and outputs information abou= t > > > that page. > > > > > > The output is presented via kernel log messages (can be accessed with > > > dmesg), and includes information such as the page's reference count, > > > mapping, flags, and memory cgroup. It also shows whether the page is > > > mapped in the kernel page table, and if so, how many times. > > > > I mean, even though I'm not a huge fan of kernel pointer hashing etc. t= his > > is obviously leaking as much information as you might want about kernel > > internal state to the point of maybe making the whole kernel pointer > > hashing thing moot. > > > > I know this requires CAP_SYS_ADMIN, but there are things that also requ= ire > > that which _still_ obscure kernel pointers. > > > > And you're outputting it all to dmesg. > > > > So yeah, a security person (Jann?) would be better placed to comment on > > this than me, but are we sure we want to do this when not in a > > CONFIG_DEBUG_VM* kernel? > > I guess there are two parts to this - what root is allowed to do, and > what information we're fine with exposing to dmesg. > > If the lockdown LSM is not set to LOCKDOWN_CONFIDENTIALITY_MAX, the > kernel allows root to read kernel memory through some interfaces - in > particular, BPF allows reading arbitrary kernel memory, and perf > allows reading at least some stuff (like kernel register states). With > lockdown in the most restrictive mode, the kernel tries to prevent > root from reading arbitrary kernel memory, but we don't really change > how much information goes into dmesg. (And I imagine you could > probably still get kernel pointers out of BPF somehow even in the most > restrictive lockdown mode, but that's probably not relevant.) > > The main issue with dmesg is that some systems make its contents > available to code that is not running with root privileges; and I > think it is also sometimes stored persistently in unencrypted form > (like in EFI pstore) even when everything else on the system is > encrypted. > So on one hand, we definitely shouldn't print the contents of random > chunks of memory into dmesg without a good reason; on the other hand, > for example we do already print kernel register state on WARN() (which > often includes kernel pointers and could theoretically include more > sensitive data too). > > So I think showing page metadata to root when requested is probably > okay as a tradeoff? And dumping that data into dmesg is maybe not > great, but acceptable as long as only root can actually trigger this? > > I don't really have a strong opinion on this... > > > To me, a bigger issue is that dump_page() looks like it might be racy, > which is maybe not terrible in debugging code that only runs when > something has already gone wrong, but bad if it is in code that root > can trigger on demand? Hi Jann, thank you for reviewing this proposal. Presumably, the interface should be used only when something has gone wrong but has not been noticed by the kernel. That something is usually checksums failures that are outside of the kernel: i.e. during live migration, snapshotting, filesystem journaling, etc. We already have interfaces that provide data from the live kernel that could be racy, i.e. crash utility. > __dump_page() copies the given page with > memcpy(), which I don't think guarantees enough atomicity with > concurrent updates of page->mapping or such, so dump_mapping() could > probably run on a bogus pointer. Even without torn pointers, I think > there could be a UAF if the page's mapping is destroyed while we're > going through dump_page(), since the page might not be locked. And in > dump_mapping(), the strncpy_from_kernel_nofault() also doesn't guard > against concurrent renaming of the dentry, which I think again would > probably result in UAF. Since we are holding a reference on the page at the time of dump_page(), the identity of the page should not really change, but dentry can be renamed. > So I think dump_page() in its current form is not something we should > expose to a userspace-reachable API. We use dump_page() all over WARN_ONs in MM code where pages might not be locked, but this is a good point, that while even the existing usage might be racy, providing a user-reachable API potentially makes it worse. I will see if I could add some locking before dump_page(), or make a dump_page variant that does not do dump_mapping().