lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 8 Oct 2021 09:43:59 +0200 From: David Hildenbrand <david@...hat.com> To: Rasmus Villemoes <linux@...musvillemoes.dk>, John Hubbard <jhubbard@...dia.com>, Suren Baghdasaryan <surenb@...gle.com>, Kees Cook <keescook@...omium.org> Cc: Michal Hocko <mhocko@...e.com>, Pavel Machek <pavel@....cz>, Andrew Morton <akpm@...ux-foundation.org>, Colin Cross <ccross@...gle.com>, Sumit Semwal <sumit.semwal@...aro.org>, Dave Hansen <dave.hansen@...el.com>, Matthew Wilcox <willy@...radead.org>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Vlastimil Babka <vbabka@...e.cz>, Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>, Al Viro <viro@...iv.linux.org.uk>, Randy Dunlap <rdunlap@...radead.org>, Kalesh Singh <kaleshsingh@...gle.com>, Peter Xu <peterx@...hat.com>, rppt@...nel.org, Peter Zijlstra <peterz@...radead.org>, Catalin Marinas <catalin.marinas@....com>, vincenzo.frascino@....com, Chinwen Chang (張錦文) <chinwen.chang@...iatek.com>, Axel Rasmussen <axelrasmussen@...gle.com>, Andrea Arcangeli <aarcange@...hat.com>, Jann Horn <jannh@...gle.com>, apopple@...dia.com, Yu Zhao <yuzhao@...gle.com>, Will Deacon <will@...nel.org>, fenghua.yu@...el.com, thunder.leizhen@...wei.com, Hugh Dickins <hughd@...gle.com>, feng.tang@...el.com, Jason Gunthorpe <jgg@...pe.ca>, Roman Gushchin <guro@...com>, Thomas Gleixner <tglx@...utronix.de>, krisman@...labora.com, Chris Hyser <chris.hyser@...cle.com>, Peter Collingbourne <pcc@...gle.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, Jens Axboe <axboe@...nel.dk>, legion@...nel.org, Rolf Eike Beer <eb@...ix.com>, Cyrill Gorcunov <gorcunov@...il.com>, Muchun Song <songmuchun@...edance.com>, Viresh Kumar <viresh.kumar@...aro.org>, Thomas Cedeno <thomascedeno@...gle.com>, sashal@...nel.org, cxfcosmos@...il.com, LKML <linux-kernel@...r.kernel.org>, linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org, linux-mm <linux-mm@...ck.org>, kernel-team <kernel-team@...roid.com> Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting On 08.10.21 09:25, Rasmus Villemoes wrote: > On 07/10/2021 21.02, John Hubbard wrote: >> On 10/7/21 11:50, Suren Baghdasaryan wrote: >> ... > >>>>> 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? >>> >>> Would love to if others are ok with this. >>> >> >> If this doesn't get accepted, then another way forward would to continue >> the ideas above to their logical conclusion, and create a new file system: >> vma-fs. > > Or: Why can't the library/application that wants a VMA backed by memory > to have some associated name not just > > fd = open("/run/named-vmas/foobar#24", O_CLOEXEC|O_RDWR|O_EXCL|O_CREAT); > unlink("/run/named-vmas/foobar#24"); > ftruncate(fd, ...); > mmap(fd); > > where /run/named-vmas is a tmpfs (probably with some per-user/per-app > subdirs). That requires no changes in the kernel at all. Yes, it lacks > the automatic cleanup of using real anon mmap in case there's a crash > between open and unlink, but in an environment like Android that should > be solvable. I'm going to point out that we already do have names for memfds. "The name supplied in name is used as a filename and will be displayed as the target of the corresponding symbolic link in the directory /proc/self/fd/." It's also displayed in /proc/self/maps. So theoretically, without any kernel changes one might be able to achieve something as proposed in this patch via memfd_create(). There is one issue to be fixed: MAP_PRIVATE on memfd results in a double memory consumption on any access via the mapping last time I checked (one page for pagecache, one page for private mapping). -- Thanks, David / dhildenb
Powered by blists - more mailing lists