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 171BAD49219 for ; Mon, 18 Nov 2024 12:54:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88E6F6B00BE; Mon, 18 Nov 2024 07:54:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83D906B00BF; Mon, 18 Nov 2024 07:54:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 705A16B00C0; Mon, 18 Nov 2024 07:54:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 537386B00BE for ; Mon, 18 Nov 2024 07:54:28 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F16F7C0151 for ; Mon, 18 Nov 2024 12:54:27 +0000 (UTC) X-FDA: 82799207988.12.00DF9C5 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf27.hostedemail.com (Postfix) with ESMTP id 864DC40004 for ; Mon, 18 Nov 2024 12:53:35 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z348ZtYZ; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731934375; 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=RFZav5imPpDajhAmqlY2eOGgnED4NjQI6+JJoDQ71N0=; b=wllDPY2QP9hzVKV2rIBBRipDb7QIB0MBsTAOCekBxWKMt3VWlBtO8E6vGvzjlshq53kdTY dsXT81uSkzyuUywWdpiFzyBSk0xa6vFbPkapdDqZrYwGAQTkSLUwYuhB6Q7KN/LodbgKLz rEUG5nMv11IBnhKI0Vk9SGjse9giw0E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731934375; a=rsa-sha256; cv=none; b=YHd/hyHl43fSvfsZJ0FneHxm5JGcxfhs5uDxC/CSDKH3554WFHSCaAvwKv0XdjtH2aIptf /FVqV9Iit4CqvPF8YalchtTDDvHzKFpdrVIYvH3DYnV2wzqhZTVwcATPEQ1zKGjUjtbKva NeFUUctMIxooNx1Lm3gI7XfIMcY3bpI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z348ZtYZ; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5cfc18d5259so6163a12.1 for ; Mon, 18 Nov 2024 04:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731934464; x=1732539264; 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=RFZav5imPpDajhAmqlY2eOGgnED4NjQI6+JJoDQ71N0=; b=z348ZtYZVPBC989QlwS9mWQ2DW3ks4LJUKYoy5fCJqyEiu9pUioNHu4qZU6RU5s+tl leoEfk7dlIw49aVctO7txlw5fCjkHnHNvcS/3SpRsgjowRzPyVQDnBPRghJN9iLHOiqv j79NnGgl27CwgeWwYJMqJIt5HGS+YoomFhYSTzYV2eJV6xEzdllxPxM+TrkVIr2JJ5b4 Gfs3g88lVp0lZRUGDARbpyIRu1PMZa/93w3mvojMzVMvNiNm/s8ES8sFBKalCN4q+NpJ lVa+FWSnq1ZEPBV7deomY6KDMojHphHSii3uZ2yjga7kGjE86MBv7/8yE+F01kq81YKQ tbyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731934464; x=1732539264; 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=RFZav5imPpDajhAmqlY2eOGgnED4NjQI6+JJoDQ71N0=; b=DjzygIQDhfN/5GW9BiQ5WrzR09nB+whKiRlJx67eLWgwJtquxzdby8rOiXvqLKHcu8 O5hX132SzGJ9ga5F5yj8wd2e3qJmeU7N7XTsBH1UiSzgpI1JtnRI+bqXGXsrCqub6ab9 fgWZYqJU0ox2BzA9X37QaR2L3ZcNOt/QzDy52jpYmNAXMsQy6hAejij6aDd8wKpxY1MY T02/2CECRft6ov5FDA8SeYDEZ43RNOaBUqPTxlRIGw6hk/0m1ZtBIGUPufcMw5iVGfRZ WWrAmT6jtFe85Pbi62nRvvOOvAIzzZtfOTzS4vDy2UoGnp8BKUko+EWpP8gyqPGsCFYq ZA+w== X-Forwarded-Encrypted: i=1; AJvYcCUKncRAmLmQhX2Fkec6ml7DVBMl8mXAIQoS2OAohe+DwFcqSthhchYPArq0jF2vAtO1QP3DOjVAdQ==@kvack.org X-Gm-Message-State: AOJu0YyUX7qMKiz2sGB20FbVyXbMTDhFqzY51GKo5k8d5InqNRBFxqPf X4exc4EaXthyp35ExxuNfvxxsvy0jsVNJzgCsOVzOuB6wcP9mQ2xBjLm810EPVJoI89mKJdZ7tq uQXyIjt+yqfLQCxtRqSjNH0UurnHgVIAwqRX0 X-Gm-Gg: ASbGnctJsYHK4wZZP3SGLBK3wub1J4PmyO6FAbd8xxh98ZYBfpOOVINg9K+OXUldoSx O9VVigZZNWMyIX8yxtqy3y7B0t7hujUEUdAWvtzqaoCgxE5NHsjLZfgumSkw= X-Google-Smtp-Source: AGHT+IFWl9n8jfw906nl94a7cbMwHIP9Gd4TNcFZWOOm8Tvrj69mcd0XEdLXVwoqv6yIo+K1feYbwLqCVdza/E5/6V8= X-Received: by 2002:aa7:de84:0:b0:5cf:6f4d:c29c with SMTP id 4fb4d7f45d1cf-5cfa298afd6mr136645a12.4.1731934463854; Mon, 18 Nov 2024 04:54:23 -0800 (PST) MIME-Version: 1.0 References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> In-Reply-To: From: Jann Horn Date: Mon, 18 Nov 2024 13:53:46 +0100 Message-ID: Subject: Re: [RFCv1 0/6] Page Detective To: Lorenzo Stoakes Cc: Pasha Tatashin , 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-Rspamd-Server: rspam10 X-Stat-Signature: g8gy8zesgkh63fqhe87xqcawoskxax1p X-Rspamd-Queue-Id: 864DC40004 X-Rspam-User: X-HE-Tag: 1731934415-845140 X-HE-Meta: U2FsdGVkX1/8DneQVnk2XC9UUWIH6XOP6o5GcDrGg6tRLA4AEwW7Xpu+iAwHsjr2iD653S/yWzXHhGcQV6jVD4vndN3rZcDkgKO8rwjoPwu+f84/+BCeY5LRMkbxPLDBQv2mF57tAVzGi/bQ7cx/0EQVBC/IKuGoQc4acN+DApBIu00b32um9ySVTjZWZ/wxsrsbf4N7hdWSDO/zFEkDobz3kNkUd8yRZhJGRm9LgvWarc3j26SrYNvXuOv1Jgj21n7KZkOa1IIpGj4+iibVhPTRpYBa0zeLgJZBrnWIMCCB/FhSaW7yrD5y7sRbdyXOiLT2wFxuyJd6fCMO4dRSE27bD/t0/Fs8Xfv7SUY4ZooJ6dvRa9n0+UWJW1hDR3ok7ttRqRd6bdehjXZ4jT2zm9NlYztLnsjfGZGaW3Yep2ISJyatHYUseqwW4pGcYzdqcNiVMQvi8x6gBdDftpdfuTy5LsMX8mnG0m5nVz0jswTPM9xzTNm8OP0irdBN5lNoPn0oJT9WmfBP/FQecMoSBVwkrMyPorBnCUoF7NQOobk73vM0VrBEn34UBO/L5eflWd+byqaLU4LbcIVO6ZWRuYypVCTHn76DYen1gWRNLUSujUSuEYzm7/zxlZSsQw4KVM4QEvoNlnxCmX6DwXqYW2toAvrj0b6N7n/gARUTW91kgO/zZ6JHeZyIUsIuP6WhK4b/i9rzaPnhRteFdBD9JgwAWjapOOGvXqFIeh5Jn/sItGV/htqZg3Ej+dbfIVYb2ckOgkXNydtm1vQPToTdg3UfPFYY3P4RItoEqJX9NpTbfoYjDk7x9n8hbZBYV4VeEzzvhpH6kZt9wPh7vGM8aqCh1zQOFCRI5QrouPX/RByPes3IYSPDc+Gaz9cxE2iNc3LsCnL1E1U//8IHijg37Fc3tVVZPFkHtbp/QXOSBCfez+VDsoiHtdTZeSP5funnzNNnxYvBXi+u8Sro41Z 0Q5pL0qj 77xs1djaJOF6rLYhUvYvG2iyFASBUFuUPL+uVIZaGZNl+4x+5s3Ry7mP6JUgYT1FwHgxEqEFDSGBdoJ/Iwoa6o2k91WK9Cps8ugCKbsgP/RXDvV7aEWHOSBTY8W65W4y9Oxpa/VZWMguE+JojFXHxJfcbD+Gf01mXkMiLlIrhlVgcckgTTnCXmkj1pVzRlZSLgr/GBxHlhhqKsUp1FSe7yHPB2lPbV8jdfQ20 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 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: "virt" > > and "phys". > > > > The "virt" file takes a virtual address and PID and outputs information > > about the corresponding page. > > > > The "phys" file takes a physical address and outputs information about > > 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. thi= s > 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 requir= e > 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? __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. So I think dump_page() in its current form is not something we should expose to a userspace-reachable API.