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 DFFF1C433F5 for ; Thu, 14 Oct 2021 20:17:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6DBEE610E6 for ; Thu, 14 Oct 2021 20:17:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6DBEE610E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B8A9A940007; Thu, 14 Oct 2021 16:17:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B3941900002; Thu, 14 Oct 2021 16:17:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0079940007; Thu, 14 Oct 2021 16:17:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 908BC900002 for ; Thu, 14 Oct 2021 16:17:00 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 547181809AEFC for ; Thu, 14 Oct 2021 20:17:00 +0000 (UTC) X-FDA: 78696151800.32.0E14348 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf05.hostedemail.com (Postfix) with ESMTP id A9CDB5081389 for ; Thu, 14 Oct 2021 20:16:58 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id q189so17553767ybq.1 for ; Thu, 14 Oct 2021 13:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c0cmuWRsBM8lyTJIMBQh8bNKy5hHUkW2gy7WXb11ikU=; b=f0qLDOKzIPAztbLgdkQY2YKlIIwOO4CPZpbMpiSv8Ew9Oil/ath9n07/ohZFTfCchC tUfFpgpxKWGSiuPuGQXa1lAJMzvJ2v2jEgfNJIChSA6p3F/PA65vL35nhyaFPtFPTu49 1247Evth3zZtmiV9KJGFY1VnR8L91bL9rPwjPym6PmsUCAowdylHSWXNeLXHESeggihA Vt1lQtjprzK6LMxeZPiVT/NtzOrDnx2xOOG8OJMrpdLwEzixkPIbxPqs1oZmLmYb8uvN owoPUF3VgkSF9BJUFMguFjxt/z84NGzPG34QC62MSK7yEjYhoPlVKw2QYEROpDMnIVFl tCsA== 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=c0cmuWRsBM8lyTJIMBQh8bNKy5hHUkW2gy7WXb11ikU=; b=KJceftmibjtRT9KK4g2fA6WFtzar2EY24/Olz2nPHoUWzMFPCk+xIBmeRo31WCp9r8 dJph6ZL7cxmEdb/MpCNS9XVJxCRZVZgDb/+8WwdNFQIcr9yKFyDfrIHcvJjWDc8zbnPt eCSr2Ktao6CZ3VWifOjWEGlmFMLjhUokY7vZ7QIZiuWndO73uMkihrsj1FWspXeYO4Sj abcCCphTYhZeUJevack4okQSgxPjEVcMgCJOKCSpvi41HXrHKfa0mPiRJsl4yjEJ97Ka 6pcHIbyBuuXrEx0q4Enp3uOkSiTJ4eSd+2aRBmO2G8AViIxbfxnHlHARGb1YWN0VPc2m EW0A== X-Gm-Message-State: AOAM532NNOFnYPyX5gNkEbEc7pDwocuhi/ZiNz4ZV1ldIw0S3B9/piS5 pYEmcu8zx8ZmjoBy6foIRQS4Nz14J7GtTFzAi2YHxw== X-Google-Smtp-Source: ABdhPJyxDeRMapi8KKC0nonneI/eCQ7+kw+lLAqFaMCn23DedEM+4BAtFbvseb+djFd5f1c00tNd4JPLKH7QEDYHlig= X-Received: by 2002:a25:5b04:: with SMTP id p4mr8493469ybb.34.1634242618619; Thu, 14 Oct 2021 13:16:58 -0700 (PDT) MIME-Version: 1.0 References: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> <26f9db1e-69e9-1a54-6d49-45c0c180067c@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 14 Oct 2021 13:16:47 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: David Hildenbrand Cc: Michal Hocko , Kees Cook , Pavel Machek , Rasmus Villemoes , 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, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A9CDB5081389 X-Stat-Signature: mwafwmot9anqty51zt1g54soerxme7cp Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=f0qLDOKz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1634242618-46872 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 Tue, Oct 12, 2021 at 10:01 AM Suren Baghdasaryan wrote: > > On Tue, Oct 12, 2021 at 12:44 AM David Hildenbrand wrote: > > > > > I'm still evaluating the proposal to use memfds but I'm not sure if > > > the issue that David Hildenbrand mentioned about additional memory > > > consumed in pagecache (which has to be addressed) is the only one we > > > will encounter with this approach. If anyone knows of any potential > > > issues with using memfds as named anonymous memory, I would really > > > appreciate your feedback before I go too far in that direction. > > > > [MAP_PRIVATE memfd only behave that way with 4k, not with huge pages, so > > I think it just has to be fixed. It doesn't make any sense to allocate a > > page for the pagecache ("populate the file") when accessing via a > > private mapping that's supposed to leave the file untouched] > > > > My gut feeling is if you really need a string as identifier, then try > > going with memfds. Yes, we might hit some road blocks to be sorted out, > > but it just logically makes sense to me: Files have names. These names > > exist before mapping and after mapping. They "name" the content. > > I'm investigating this direction. I don't have much background with > memfds, so I'll need to digest the code first. I've done some investigation into the possibility of using memfds to name anonymous VMAs. Here are my findings: 1. Forking a process with anonymous vmas named using memfd is 5-15% slower than with prctl (depends on the number of VMAs in the process being forked). Profiling shows that i_mmap_lock_write() dominates dup_mmap(). Exit path is also slower by roughly 9% with free_pgtables() and fput() dominating exit_mmap(). Fork performance is important for Android because almost all processes are forked from zygote, therefore this limitation already makes this approach prohibitive. 2. mremap() usage to grow the mapping has an issue when used with memfds: fd = memfd_create(name, MFD_ALLOW_SEALING); ftruncate(fd, size_bytes); ptr = mmap(NULL, size_bytes, prot, MAP_PRIVATE, fd, 0); close(fd); ptr = mremap(ptr, size_bytes, size_bytes * 2, MREMAP_MAYMOVE); touch_mem(ptr, size_bytes * 2); This would generate a SIGBUS in touch_mem(). I believe it's because ftruncate() specified the size to be size_bytes and we are accessing more than that after remapping. prctl() does not have this limitation and we do have a usecase for growing a named VMA. 3. Leaves an fd exposed, even briefly, which may lead to unexpected flaws (e.g. anything using mmap MAP_SHARED could allow exposures or overwrites). Even MAP_PRIVATE, if an attacker writes into the file after ftruncate() and before mmap(), can cause private memory to be initialized with unexpected data. 4. There is a usecase in the Android userspace where vma naming happens after memory was allocated. Bionic linker does in-memory relocations and then names some relocated sections. In the light of these findings, could the current patchset be reconsidered? Thanks, Suren. > > > > > Maybe it's just me, but the whole interface, setting the name via a > > prctl after the mapping was already instantiated doesn't really spark > > joy at my end. That's not a strong pushback, but if we can avoid it > > using something that's already there, that would be very much preferred. > > Actually that's one of my worries about using memfds. There might be > cases when we need to name a vma after it was mapped. memfd_create() > would not allow us to do that AFAIKT. But I need to check all usages > to say if that's really an issue. > Thanks! > > > > > -- > > Thanks, > > > > David / dhildenb > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. > >