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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 815D9C433F5 for ; Thu, 9 Sep 2021 17:32:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C95361100 for ; Thu, 9 Sep 2021 17:32:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236506AbhIIRdf (ORCPT ); Thu, 9 Sep 2021 13:33:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235813AbhIIRde (ORCPT ); Thu, 9 Sep 2021 13:33:34 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87CFEC061574 for ; Thu, 9 Sep 2021 10:32:24 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id m28so5200311lfj.6 for ; Thu, 09 Sep 2021 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPjDsk9Q1h6DRiZrMZmPS/GH+AL3OHxxk/T+hteUu20=; b=BCZ8Zgn6lh0HwTDFtxVtrfcHjC5t2qXeaauShBCl/aDEJGz2yWxlijBwKAC8N3Zc7B FVn/I9ruFCEQQZZwZB+qo4yvWaQYoVinFfaqpCKhTCyi3cksysB7oMYKwPzIP/OaNIiD 4j/fCYJ1SxTlbkabBEdECKDp+nC7zomesrbd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPjDsk9Q1h6DRiZrMZmPS/GH+AL3OHxxk/T+hteUu20=; b=ZH0oTDRn146EgYW7lmTlB8oo4YsJv18SCSjHxzx1To/X0St3/uoR1nc1b0nJxos/c+ LapKY012N/KwwZW3KqZ+3c95GGd1u1pZUEjjso3LAHKSXvejEUO6DBaoq5k+xDqWoGTS 2YqjE+U/Ikgwhr7lWgEjc3EypNEjcmyDmfAwUsfNaeLuWPSiefghLnn3wMWfQoJ1X0kR KfXGn8sB59FQPa2FfNZH2guCA0G0R6dD/POX3Nq8qagMwBW23SoFJEwoPXQNokG8fKdm fgzUxndmhFMz1fJjx5ay0JVCdJ0ajruUmXvsKQOrNM0Xgk5nkBC4oYwewQ4PG55303Ez D2dQ== X-Gm-Message-State: AOAM530EJbWTZwRFPXjngmLUiQGDnqL2T9ws1sIprECt/wJiY+lW8h7o OYjKfcep7jtI2H/CpVEbGfTkbcUV8Q3ruyQ9RN8= X-Google-Smtp-Source: ABdhPJznf8UXGWH/zVgLkyy/YzZOZmu9Uc5mgoWQrxK1fSTXjQ0vZSpqIo8jK6rVUGaVyvarand8ww== X-Received: by 2002:a05:6512:6d4:: with SMTP id u20mr720608lff.17.1631208742670; Thu, 09 Sep 2021 10:32:22 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id n6sm261469lfb.102.2021.09.09.10.32.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 10:32:22 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id c8so5229146lfi.3 for ; Thu, 09 Sep 2021 10:32:21 -0700 (PDT) X-Received: by 2002:a05:6512:2611:: with SMTP id bt17mr746379lfb.141.1631208741606; Thu, 09 Sep 2021 10:32:21 -0700 (PDT) MIME-Version: 1.0 References: <20210907195226.14b1d22a07c085b22968b933@linux-foundation.org> <20210908025730.S88ylmikU%akpm@linux-foundation.org> In-Reply-To: From: Linus Torvalds Date: Thu, 9 Sep 2021 10:32:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [External] Re: [patch 079/147] fs/proc/kcore.c: add mmap interface To: Feng Zhou Cc: Andrew Morton , Alexey Dobriyan , chenying.kernel@bytedance.com, Linux-MM , mm-commits@vger.kernel.org, Mike Rapoport , Muchun Song , zhouchengming@bytedance.com, zhengqi.arch@bytedance.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org On Thu, Sep 9, 2021 at 2:57 AM Feng Zhou wrote: > > Compared to the read interface, kcore mmap has no increased risk, just > reduce context switching. Yes, but the main worry is "do we really need to make this faster and easier"? Because one of the possible main users is literally the black hat "I got root, now I want to do a rootkit". And mmap is very very different from read(). Why? Because using mmap() you can now track changes in realtime (ie you poll waiting for some memory location to change, possibly even with hardware assist - like watchpoints or ring3 "monitor/mwait"). So mmap() of the kernel memory literally acts as a prime tool for looking at and exploiting races. Which is why I'm _very_ leery of these kinds of interfaces. Do they have possible good uses? Yes. But the bad uses seem to actually dominate. The good users don't seem _that_ critical, while the bad users would seem to absolutely love this interface. See my argument? This is basically a very dangerous interface. The fact that it is read-only doesn't change that at all. Linus 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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 54705C433EF for ; Thu, 9 Sep 2021 17:32:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 16F4E61100 for ; Thu, 9 Sep 2021 17:32:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 16F4E61100 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1CBA46B006C; Thu, 9 Sep 2021 13:32:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17BF56B0072; Thu, 9 Sep 2021 13:32:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06ADE6B0073; Thu, 9 Sep 2021 13:32:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id E87116B006C for ; Thu, 9 Sep 2021 13:32:25 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7C13A32609 for ; Thu, 9 Sep 2021 17:32:25 +0000 (UTC) X-FDA: 78568729050.27.D3E03F7 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf24.hostedemail.com (Postfix) with ESMTP id 3B8D8B00009F for ; Thu, 9 Sep 2021 17:32:25 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id n2so5270927lfk.0 for ; Thu, 09 Sep 2021 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPjDsk9Q1h6DRiZrMZmPS/GH+AL3OHxxk/T+hteUu20=; b=BCZ8Zgn6lh0HwTDFtxVtrfcHjC5t2qXeaauShBCl/aDEJGz2yWxlijBwKAC8N3Zc7B FVn/I9ruFCEQQZZwZB+qo4yvWaQYoVinFfaqpCKhTCyi3cksysB7oMYKwPzIP/OaNIiD 4j/fCYJ1SxTlbkabBEdECKDp+nC7zomesrbd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPjDsk9Q1h6DRiZrMZmPS/GH+AL3OHxxk/T+hteUu20=; b=lU+qSdJnc2LfEOYjmjatx532ifE/m6sQen82Yfiuyz0IjIbKqlLtm0tIr7G2d7FXmd CclN9/ZPxDKIkxZQ6qoKiGLl7zzO7ojchqnL5DogG7NjWU7Yxwrq6vAJjfoTMBVQsCcV kcyl/mSR04UUue6VZCE43grMeAOK+9wt0pnSuwmRWeSeZKC11JEcE23WPmtzbNjwrDwN EWaHg7JkxCO9bwDxIMwenM++W0TECIVmAmUnIVvwvOFXmUCGBdiDvchyUsPvYDxUhULy tBMZxqN4/1ohQBk5DwyAueQBmQj9n0HNAiLIWJGqatG4u+9odTluE7u6SxNps3YPlqrw 2Zfw== X-Gm-Message-State: AOAM531GWXkAYm3u/XeEEFJcPgjGOXF2d4m0pqpzYOPjKoYijtOSEm+E 7iuTfs6dIvzsK/ONvWp/2oIVkVpxUynLIpwDHVw= X-Google-Smtp-Source: ABdhPJwVy6mHmbHJKj09Q4OU/98PJBOS3sdfvQftxrm4cKMZJ3H9RIGDMUHp9BTMkr+m5cMIEiSBsQ== X-Received: by 2002:a05:6512:169b:: with SMTP id bu27mr775460lfb.578.1631208742753; Thu, 09 Sep 2021 10:32:22 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id d1sm263953lfl.5.2021.09.09.10.32.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 10:32:22 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id f18so5150669lfk.12 for ; Thu, 09 Sep 2021 10:32:21 -0700 (PDT) X-Received: by 2002:a05:6512:2611:: with SMTP id bt17mr746379lfb.141.1631208741606; Thu, 09 Sep 2021 10:32:21 -0700 (PDT) MIME-Version: 1.0 References: <20210907195226.14b1d22a07c085b22968b933@linux-foundation.org> <20210908025730.S88ylmikU%akpm@linux-foundation.org> In-Reply-To: From: Linus Torvalds Date: Thu, 9 Sep 2021 10:32:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [External] Re: [patch 079/147] fs/proc/kcore.c: add mmap interface To: Feng Zhou Cc: Andrew Morton , Alexey Dobriyan , chenying.kernel@bytedance.com, Linux-MM , mm-commits@vger.kernel.org, Mike Rapoport , Muchun Song , zhouchengming@bytedance.com, zhengqi.arch@bytedance.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3B8D8B00009F X-Stat-Signature: 7oskjcdx447uocf9dap9zurcr7yry5iw Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BCZ8Zgn6; spf=pass (imf24.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1631208745-170357 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 Thu, Sep 9, 2021 at 2:57 AM Feng Zhou wrote: > > Compared to the read interface, kcore mmap has no increased risk, just > reduce context switching. Yes, but the main worry is "do we really need to make this faster and easier"? Because one of the possible main users is literally the black hat "I got root, now I want to do a rootkit". And mmap is very very different from read(). Why? Because using mmap() you can now track changes in realtime (ie you poll waiting for some memory location to change, possibly even with hardware assist - like watchpoints or ring3 "monitor/mwait"). So mmap() of the kernel memory literally acts as a prime tool for looking at and exploiting races. Which is why I'm _very_ leery of these kinds of interfaces. Do they have possible good uses? Yes. But the bad uses seem to actually dominate. The good users don't seem _that_ critical, while the bad users would seem to absolutely love this interface. See my argument? This is basically a very dangerous interface. The fact that it is read-only doesn't change that at all. Linus