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 X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67C4DC433E0 for ; Fri, 19 Mar 2021 14:46:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0A95864DFB for ; Fri, 19 Mar 2021 14:46:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A95864DFB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 96C176B006E; Fri, 19 Mar 2021 10:46:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 943076B0073; Fri, 19 Mar 2021 10:46:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7969C6B0078; Fri, 19 Mar 2021 10:46:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 5DB866B006E for ; Fri, 19 Mar 2021 10:46:04 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 214E0181A88D0 for ; Fri, 19 Mar 2021 14:46:04 +0000 (UTC) X-FDA: 77936898606.28.201BBEC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 78D0D80194E6 for ; Fri, 19 Mar 2021 14:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616165148; h=from:from: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; bh=8KGbLZQ7O+JfyAjTpujJt4QAW5NJjPJMsJ4wbUnlwTM=; b=CvlP1te7ffFbCx+SuET4L+EGIM1PE7H0wYu/dM+U8u6YyziUpFtwhA80BgiR2pv9Vlb5VZ PEyUXUZYOPsyFWfZr3SnOh72T/thOx1GqtzbQoPLPBASrnPfxGVYb8cVh4A8V9i9kbN8ra Hle3d305THbHb9uBbX9va9Kuk7rO9Kk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616165150; h=from:from: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; bh=8KGbLZQ7O+JfyAjTpujJt4QAW5NJjPJMsJ4wbUnlwTM=; b=VsXkdScF9ChcX1jmX8gmKliflOr2+OsnZnUk/tKEGUvBSA7K5mDAGNBdazyTOVqf4d93Tb QcbyLzsfQsCN4uddusVbjFB6gQNHT+lvyOS5Tl8qSaJTarqollFJilE4EOmo9QEJr9Ex0L uYKJDJvED3d643J+Bx1GNYp9eHJRuh8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-114-jni7oloINl2Lbs_c0PQHfg-1; Fri, 19 Mar 2021 10:45:46 -0400 X-MC-Unique: jni7oloINl2Lbs_c0PQHfg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2176B81744F; Fri, 19 Mar 2021 14:45:41 +0000 (UTC) Received: from [10.36.112.11] (ovpn-112-11.ams2.redhat.com [10.36.112.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9858D6090F; Fri, 19 Mar 2021 14:45:26 +0000 (UTC) Subject: Re: [PATCH RFC 0/3] drivers/char: remove /dev/kmem for good To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, "Alexander A. Klimov" , Alexander Viro , Alexandre Belloni , Andrew Lunn , Andrew Morton , Andrey Zhizhikin , Arnd Bergmann , Benjamin Herrenschmidt , Brian Cain , Christian Borntraeger , Christophe Leroy , Chris Zankel , Corentin Labbe , "David S. Miller" , "Eric W. Biederman" , Geert Uytterhoeven , Gerald Schaefer , Greentime Hu , Greg Kroah-Hartman , Gregory Clement , Heiko Carstens , Helge Deller , Hillf Danton , huang ying , Ingo Molnar , Ivan Kokshaysky , "James E.J. Bottomley" , Jiaxun Yang , Jonas Bonn , Jonathan Corbet , Kairui Song , Krzysztof Kozlowski , Kuninori Morimoto , Linus Torvalds , Linux API , Liviu Dudau , Lorenzo Pieralisi , Luc Van Oostenryck , Luis Chamberlain , Matthew Wilcox , Matt Turner , Max Filippov , Michael Ellerman , Michal Hocko , Mike Rapoport , Mikulas Patocka , Minchan Kim , Niklas Schnelle , Oleksiy Avramchenko , Palmer Dabbelt , Paul Mackerras , "Pavel Machek (CIP)" , Pavel Machek , "Peter Zijlstra (Intel)" , Pierre Morel , Randy Dunlap , Richard Henderson , Rich Felker , Robert Richter , Rob Herring , Russell King , Sam Ravnborg , Sebastian Andrzej Siewior , Sebastian Hesselbarth , Stafford Horne , Stefan Kristiansson , Steven Rostedt , Sudeep Holla , Theodore Dubois , Thomas Bogendoerfer , Thomas Gleixner , Vasily Gorbik , Viresh Kumar , William Cohen , Xiaoming Ni , Yoshinori Sato References: <20210319143452.25948-1-david@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <39b945bc-003c-4fb3-17ad-3484b6196bd3@redhat.com> Date: Fri, 19 Mar 2021 15:45:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210319143452.25948-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Stat-Signature: 9ce3a3z1zaj6o7fkwmirb4muswjz45yx X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 78D0D80194E6 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616165147-975287 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: On 19.03.21 15:34, David Hildenbrand wrote: > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. > > More details / findings in patch #1. Patch #2 and #3 perform minor cleanups > based on removed /dev/kmem support. As some arch maintainers are only cced on patch #2 (grml), patch #1 is https://lkml.kernel.org/r/20210319143452.25948-2-david@redhat.com and the description is: " Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and memory ballooning, I started questioning the existance of /dev/kmem. Comparing it with the /proc/kcore implementation, it does not seem to be able to deal with things like a) Pages unmapped from the direct mapping (e.g., to be used by secretmem) -> kern_addr_valid(). virt_addr_valid() is not sufficient. b) Special cases like gart aperture memory that is not to be touched -> mem_pfn_is_ram() Unless I am missing something, it's at least broken in some cases and might fault/crash the machine. Looks like its existance has been questioned before in 2005 and 2010 [1], after ~11 additional years, it might make sense to revive the discussion. CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by mistake?). All distributions I looked at disable it. 1) /dev/kmem was popular for rootkits [2] before it got disabled basically everywhere. Ubuntu documents [3] "There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits.". RHEL documents in a BZ [5] "it served no practical purpose other than to serve as a potential security problem or to enable binary module drivers to access structures/functions they shouldn't be touching" 2) /proc/kcore is a decent interface to have a controlled way to read kernel memory for debugging puposes. (will need some extensions to deal with memory offlining/unplug, memory ballooning, and poisoned pages, though) 3) It might be useful for corner case debugging [1]. KDB/KGDB might be a better fit, especially, to write random memory; harder to shoot yourself into the foot. 4) "Kernel Memory Editor" hasn't seen any updates since 2000 and seems to be incompatible with 64bit [1]. For educational purposes, /proc/kcore might be used to monitor value updates -- or older kernels can be used. 5) It's broken on arm64, and therefore, completely disabled there. Looks like it's essentially unused and has been replaced by better suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's just remove it. [1] https://lwn.net/Articles/147901/ [2] https://www.linuxjournal.com/article/10505 [3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled [4] https://sourceforge.net/projects/kme/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=154796 " -- Thanks, David / dhildenb