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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 CCD23C432BE for ; Mon, 30 Aug 2021 17:03:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 601D960232 for ; Mon, 30 Aug 2021 17:03:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 601D960232 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 89ED08D0001; Mon, 30 Aug 2021 13:03:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84E346B0072; Mon, 30 Aug 2021 13:03:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73D1A8D0001; Mon, 30 Aug 2021 13:03:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id 6449E6B0071 for ; Mon, 30 Aug 2021 13:03:39 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0D4381944C for ; Mon, 30 Aug 2021 17:03:39 +0000 (UTC) X-FDA: 78532368558.26.C036CE5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 3A586900024A for ; Mon, 30 Aug 2021 17:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xoB9y/6gb5tvI+qqY/ALh9vMOrQQ9QlAyNC2IX3tc1Y=; b=pqZfVDzw4vekFytMGTd+nWCCR8 2YO5nnghGG2115wp916H67WC44RJL9F0/DeML/IkIabm+LR2wvHyAok6I3oHh6Axa9yufbd4+LYjx doZkgz/i7MqsMhY8LYZePDVgGDNyXh947bd+P/ghJT/ePsYjVsJURruhNp4aEO5QqrLKmIIfyWudl 8eAY6GmK6ZhUo2HYv4dsXb5gIYpULHzMCdyK8iaEZb1wdlf1UGuYdTlO2yw0au6tLyxDKVBOcJtEm vUeyPfSGhfyZEy+jr+e9eMOHZFqPagB/WsG4e4noe+wRFWjha8yZ3lCS5TlSiPaW4GZ3p5kChwJr7 sILUD6WQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKkci-000LX7-Qk; Mon, 30 Aug 2021 16:59:09 +0000 Date: Mon, 30 Aug 2021 17:59:04 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Rasmus Villemoes , Kees Cook , Andrew Morton , Colin Cross , Sumit Semwal , Michal Hocko , Dave Hansen , "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, John Hubbard , 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@oracle.com, Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , 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 v8 2/3] mm: add a field to store names for private anonymous memory Message-ID: References: <20210827191858.2037087-1-surenb@google.com> <20210827191858.2037087-3-surenb@google.com> <202108272228.7D36F0373@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pqZfVDzw; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3A586900024A X-Stat-Signature: fg1timbyztzy951u8uusce6n3r9jcrip X-HE-Tag: 1630343017-289667 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 Mon, Aug 30, 2021 at 09:16:14AM -0700, Suren Baghdasaryan wrote: > On Mon, Aug 30, 2021 at 1:12 AM Rasmus Villemoes > wrote: > > > > On 28/08/2021 23.47, Suren Baghdasaryan wrote: > > > On Fri, Aug 27, 2021 at 10:52 PM Kees Cook wrote: > > >> > > >>>> + case PR_SET_VMA_ANON_NAME: > > >>>> + name = strndup_user((const char __user *)arg, > > >>>> + ANON_VMA_NAME_MAX_LEN); > > >>>> + > > >>>> + if (IS_ERR(name)) > > >>>> + return PTR_ERR(name); > > >>>> + > > >>>> + for (pch = name; *pch != '\0'; pch++) { > > >>>> + if (!isprint(*pch)) { > > >>>> + kfree(name); > > >>>> + return -EINVAL; > > >>> > > >>> I think isprint() is too weak a check. For example, I would suggest > > >>> forbidding the following characters: ':', ']', '[', ' '. Perhaps > > > > Indeed. There's also the issue that the kernel's ctype actually > > implements some almost-but-not-quite latin1, so (some) chars above 0x7f > > would also pass isprint() - while everybody today expects utf-8, so the > > ability to put almost arbitrary sequences of chars with the high bit set > > could certainly confuse some parsers. IOW, don't use isprint() at all, > > just explicitly check for the byte values that we and up agreeing to > > allow/forbid. > > > > >>> isalnum() would be better? (permit a-zA-Z0-9) I wouldn't necessarily > > >>> be opposed to some punctuation characters, but let's avoid creating > > >>> confusion. Do you happen to know which characters are actually in use > > >>> today? > > >> > > >> There's some sense in refusing [, ], and :, but removing " " seems > > >> unhelpful for reasonable descriptors. As long as weird stuff is escaped, > > >> I think it's fine. Any parser can just extract with m|\[anon:(.*)\]$| > > > > > > I see no issue in forbidding '[' and ']' but whitespace and ':' are > > > currently used by Android. Would forbidding or escaping '[' and ']' be > > > enough? > > > > how about allowing [0x20, 0x7e] except [0x5b, 0x5d], i.e. all printable > > (including space) ascii characters, except [ \ ] - the brackets as > > already discussed, and backslash because then there's nobody who can get > > confused about whether there's some (and then which?) escaping mechanism > > in play - "\n" is simply never going to appear. Simple rules, easy to > > implement, easy to explain in a man page. > > Thanks for the suggestion, Rasmus. I'm all for keeping it simple. > Kees, Matthew, would that be acceptable? Yes, I think so. It permits all kinds of characters that might be confusing if passed on to something else, but we can't prohibit everything, and forbidding just these three should remove any confusion for any parser of /proc. Little Bobby Tables thanks you.