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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7276C4332F for ; Thu, 7 Oct 2021 18:13:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4E3F961261 for ; Thu, 7 Oct 2021 18:13:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4E3F961261 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DD8B66B006C; Thu, 7 Oct 2021 14:13:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D86C9940008; Thu, 7 Oct 2021 14:13:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB2C4940007; Thu, 7 Oct 2021 14:13:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id 9B1566B006C for ; Thu, 7 Oct 2021 14:13:01 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 381A718423868 for ; Thu, 7 Oct 2021 18:13:01 +0000 (UTC) X-FDA: 78670437762.13.C36CD9F Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf10.hostedemail.com (Postfix) with ESMTP id CE5A96003942 for ; Thu, 7 Oct 2021 18:13:00 +0000 (UTC) Received: by mail-pf1-f176.google.com with SMTP id g2so6018501pfc.6 for ; Thu, 07 Oct 2021 11:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=o4WwfSdG/6KRIuI/J9zyZX24q26V4qiHr2+KV/sCerI=; b=UFWObsTY+6ez5xDu9StX0xHOEvb0Awqkv0IojxdYI+PxQZVMQnm1+78GXylVO7eQKc unCWRkoNBPz+dlTqyMSHkXjEyBSrxvIoYe8zqlUquJAovzzTTAutOaWA2u7XXWw+cqmI 8LjuIEZ3xAwyUSETK/5DPVjRVFkuDfq7sRi3w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=o4WwfSdG/6KRIuI/J9zyZX24q26V4qiHr2+KV/sCerI=; b=zkI43GR116Yyn03+rBqa3e8q5WIKNubGkwZeKmvvtjzdkzkn3NIPKpwQHEBinZvNL4 k91lIzesQmcl82/VM8jWDHtbY/G8Zi+KMfg1msNlUhEU3ZNDfYWyuLt7nIVs+v1RVuGm aK0V4cSDFMfZ7TQIhMUVXDG5tH7G4uFGviOWQv2wfP/eCrm48pGtGPbMzd63dtFTPNYH 8NmYB6B4M9wENjN7LuIE+2IZjRas2n8Pumn3DPrmiLwjSo/OyExBZ0eYeS9aRMV9p1Lz 0WFQuWDvdX89xURA4olEcgy2uatAJlYgw+vxPxTQGsMPL9pbnyZXm8xXVaizp/7Z3h03 usbw== X-Gm-Message-State: AOAM5309vUCuoy6zWSWs5g2sIFcx911fpnXd2woHBM+kgbl+uqV57Bn5 PsrDRBUVPFfA1IdXa/qLu7lYdw== X-Google-Smtp-Source: ABdhPJwSg+58niV4vPup/bWS/NCxrnl+eE4p/Fjn93JargziJ6r/R5cJnbLK3rzcm1kJQTUPRYo/ew== X-Received: by 2002:a62:5ac6:0:b0:44c:b979:afe3 with SMTP id o189-20020a625ac6000000b0044cb979afe3mr5778529pfb.61.1633630379668; Thu, 07 Oct 2021 11:12:59 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id l10sm106280pff.119.2021.10.07.11.12.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 11:12:59 -0700 (PDT) Date: Thu, 7 Oct 2021 11:12:58 -0700 From: Kees Cook To: Suren Baghdasaryan Cc: Michal Hocko , Pavel Machek , Rasmus Villemoes , David Hildenbrand , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, Chris Hyser , Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: <202110071111.DF87B4EE3@keescook> References: <20211006175821.GA1941@duo.ucw.cz> <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: CE5A96003942 X-Stat-Signature: iddd1k57guf4m9rzjojb78di5y9p5f8s Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=UFWObsTY; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf10.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.176 as permitted sender) smtp.mailfrom=keescook@chromium.org X-HE-Tag: 1633630380-392242 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, Oct 07, 2021 at 10:50:24AM -0700, Suren Baghdasaryan wrote: > On Thu, Oct 7, 2021 at 10:31 AM Michal Hocko wrote: > > > > On Thu 07-10-21 09:58:02, Suren Baghdasaryan wrote: > > > On Thu, Oct 7, 2021 at 9:40 AM Michal Hocko wrote: > > > > > > > > On Thu 07-10-21 09:04:09, Suren Baghdasaryan wrote: > > > > > On Thu, Oct 7, 2021 at 3:15 AM Pavel Machek wrote: > > > > > > > > > > > > Hi! > > > > > > > > > > > > > >> Hmm, so the suggestion is to have some directory which contains files > > > > > > > >> representing IDs, each containing the string name of the associated > > > > > > > >> vma? Then let's say we are creating a new VMA and want to name it. We > > > > > > > >> would have to scan that directory, check all files and see if any of > > > > > > > >> them contain the name we want to reuse the same ID. > > > > > > > > > > > > > > > > I believe Pavel meant something as simple as > > > > > > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > > > > > > > $ touch $YOUR_FILE > > > > > > > > $ stat -c %i $YOUR_FILE > > > > > > > > > > Ah, ok, now I understand the proposal. Thanks for the clarification! > > > > > So, this would use filesystem as a directory for inode->name mappings. > > > > > One rough edge for me is that the consumer would still need to parse > > > > > /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of > > > > > just dumping the content for the user. Would it be acceptable if we > > > > > require the ID provided by prctl() to always be a valid inode and > > > > > show_map_vma() would do the inode-to-filename conversion when > > > > > generating maps/smaps files? I know that inode->dentry is not > > > > > one-to-one mapping but we can simply output the first dentry name. > > > > > WDYT? > > > > > > > > No. You do not want to dictate any particular way of the mapping. The > > > > above is just one way to do that without developing any actual mapping > > > > yourself. You just use a filesystem for that. Kernel doesn't and > > > > shouldn't understand the meaning of those numbers. It has no business in > > > > that. > > > > > > > > In a way this would be pushing policy into the kernel. > > > > > > I can see your point. Any other ideas on how to prevent tools from > > > doing this id-to-name conversion themselves? > > > > I really fail to understand why you really want to prevent them from that. > > Really, the whole thing is just a cookie that kernel maintains for memory > > mappings so that two parties can understand what the meaning of that > > mapping is from a higher level. They both have to agree on the naming > > but the kernel shouldn't dictate any specific convention because the > > kernel _doesn't_ _care_. These things are not really anything actionable > > for the kernel. It is just a metadata. > > The desire is for one of these two parties to be a human who can get > the data and use it as is without additional conversions. > /proc/$pid/maps could report FD numbers instead of pathnames, which > could be converted to pathnames in userspace. However we do not do > that because pathnames are more convenient for humans to identify a > specific resource. Same logic applies here IMHO. Yes, please. It really seems like the folks that are interested in this feature want strings. (I certainly do.) For those not interested in the feature, it sounds like a CONFIG to keep it away would be sufficient. Can we just move forward with that? -- Kees Cook