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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 13 Jul 2021 00:57:59 +0000 From: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" <longpeng2@...wei.com> To: Matthew Wilcox <willy@...radead.org> CC: Steven Sistare <steven.sistare@...cle.com>, Anthony Yznaga <anthony.yznaga@...cle.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Gonglei (Arei)" <arei.gonglei@...wei.com> Subject: RE: [RFC PATCH 0/5] madvise MADV_DOEXEC Hi Matthew, > -----Original Message----- > From: Matthew Wilcox [mailto:willy@...radead.org] > Sent: Monday, July 12, 2021 9:30 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > <longpeng2@...wei.com> > Cc: Steven Sistare <steven.sistare@...cle.com>; Anthony Yznaga > <anthony.yznaga@...cle.com>; linux-kernel@...r.kernel.org; > linux-mm@...ck.org; Gonglei (Arei) <arei.gonglei@...wei.com> > Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC > > On Mon, Jul 12, 2021 at 09:05:45AM +0800, Longpeng (Mike, Cloud > Infrastructure Service Product Dept.) wrote: > > Let me describe my use case more clearly (just ignore if you're not > > interested in it): > > > > 1. Prog A mmap() 4GB memory (anon or file-mapping), suppose the > > allocated VA range is [0x40000000,0x140000000) > > > > 2. Prog A specifies [0x48000000,0x50000000) and > > [0x80000000,0x100000000) will be shared by its child. > > > > 3. Prog A fork() Prog B and then Prog B exec() a new ELF binary. > > > > 4. Prog B notice the shared ranges (e.g. by input parameters or ...) > > and remap them to a continuous VA range. > > This is dangerous. There must be an active step for Prog B to accept Prog A's > ranges into its address space. Otherwise Prog A could almost completely fill > Prog B's address space and so control where Prog B places its mappings. It > could also provoke a latent bug in Prog B if it doesn't handle address space > exhaustion gracefully. > > I had a proposal to handle this. Would it meet your requirements? > https://lore.kernel.org/lkml/20200730152250.GG23808@casper.infradead.org/ I noticed your proposal of project Sileby and I think it can meet Steven's requirement, but I not sure whether it's suitable for mine because there's no sample code yet, is it in progress ? According to the abstract of Sileby, I have two questions: 1. Would you plan to support the file-mapping memory sharing ? e.g. Prog A's 4G memory is backend with 2M hugetlb. 2. Does each mshare fd only containe one sharing VMA ? For large memory process (1T~4T in our env), maybe there is hundreds of memory ranges need to be shared, this will take too much fd space if so ?
Powered by blists - more mailing lists