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 57085C433EF for ; Fri, 8 Oct 2021 20:58:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E24F560F44 for ; Fri, 8 Oct 2021 20:58:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E24F560F44 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 785AB6B0071; Fri, 8 Oct 2021 16:58:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7349D940007; Fri, 8 Oct 2021 16:58:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D9136B0073; Fri, 8 Oct 2021 16:58:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 50ED46B0071 for ; Fri, 8 Oct 2021 16:58:04 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 18D502C6BE for ; Fri, 8 Oct 2021 20:58:04 +0000 (UTC) X-FDA: 78674482488.31.1BD853C Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf19.hostedemail.com (Postfix) with ESMTP id C9A03B00208F for ; Fri, 8 Oct 2021 20:58:03 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id m14so9160076pfc.9 for ; Fri, 08 Oct 2021 13:58:03 -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=IjJJiWQU/XhRbwSW4a6J5pEI82Dwvbf4Msp/9IsGztA=; b=fuF/48s/XKLjw/WxekTae8fxsnWdv9YZmnzgUBVcpUj7wDFyoAh9dbVeWHwfDtkKDu RiFV0cdkUHd/WrfAjkgqUH34GYwNOU8Km6wcNGt+b1nCWLn47S0Ft8Xq1zZt+StdVMvU jBfM3LscUBzEFw2GiqY3yuUIwXQjskDaNCMz4= 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=IjJJiWQU/XhRbwSW4a6J5pEI82Dwvbf4Msp/9IsGztA=; b=uXjlx8wLYraDCwC72MCk6t/vWe+AjdnKn+vk4b7IgqDKF3SJCAMv2plO4qQK1lnL1H 6uEdocn6UdsfRYOlgA18AVpUxfkrFGHLFlUYWqTLxMoCuf6iOCXAYoBYK0wVAg207cd2 Q+z8xhrBl9+yS+KHX6HnAOQIQm8n8qUDNDEp0B6380sxDPY29bLDg69YSqQo/qckifwh e8OU5nxx7/6XbLIum3VzHXMECyet7m87j5mAfiepXRDDtRP2hmVZNAvVftCGjugqLEZV inx5uIynGc9ULEARDf7JzRROCrLcw4cRHCrgDQpXBtNpv5bbM6WWdEPw5E7kiGOJ4Pw4 TUaA== X-Gm-Message-State: AOAM531stTvjHYUYEs/Ak+hHn8AqFkyAPs88A8DqdzNk6ODzjHEj3EkY yaChJIiiaJDbKggZiWKtAWdTKg== X-Google-Smtp-Source: ABdhPJyrGB7dBpiaDnYPnJIbaaQdWSM4FfIArdEe62p0xJjdD6l8chOBq8mOvXFxCXKn2tBgDNxRKA== X-Received: by 2002:a63:d2:: with SMTP id 201mr6488991pga.400.1633726682737; Fri, 08 Oct 2021 13:58:02 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b1sm222008pfm.38.2021.10.08.13.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 13:58:02 -0700 (PDT) Date: Fri, 8 Oct 2021 13:58:01 -0700 From: Kees Cook To: Michal Hocko Cc: Suren Baghdasaryan , 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: <202110081344.FE6A7A82@keescook> References: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C9A03B00208F X-Stat-Signature: 5txj9a578mkzh85ge86htrm5mbr886zg Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="fuF/48s/"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf19.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.175 as permitted sender) smtp.mailfrom=keescook@chromium.org X-HE-Tag: 1633726683-712404 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 Fri, Oct 08, 2021 at 08:34:47AM +0200, Michal Hocko wrote: > I am sorry but there were no strong arguments mentioned for strings so > far. Effectively string require a more complex and more resource hungry > solution. The only advantage is that strings are nicer to read for > humans. How I see it: - Strings are already present in the "maps" output, so this doesn't create a burden on userspace to grow new parsers. - Strings for "anon" specifically have no required format (this is good) it's informational like the task_struct::comm and can (roughly) anything. There's no naming convention for memfds, AF_UNIX, etc. Why is one needed here? That seems like a completely unreasonable requirement. - Strings need to be in kernel space because cross-process GUP has been a constant source of security flaws. > There hasn't been any plan presented for actual naming convention or how > those names would be used in practice. Except for a more advanced > resource management and that sounds like something that can work with > ids just fine. There doesn't need to be and there shouldn't be. Why aren't memfds names an id? Because, to quote the man-page, "... serves only for debugging purposes. Names do not affect the behavior of the file descriptor, and as such multiple files can have the same name without any side effects." And they aren't filtered _at all_ either. I think the anonymous vma name series has gone out of its way to be safe and sane while still providing the ease-of-use that it was designed to provide. > Initially I was not really feeling strongly one way or other but more we > are discussing the topic the more I see that strings have a very weak > justification behind. I just don't see any _down_ side to gaining this. There's only resource utilization when it's used, and the complexity is minimal. -- Kees Cook