Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Sistare <firstname.lastname@example.org>
To: Matthew Wilcox <email@example.com>
Cc: Anthony Yznaga <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC
Date: Thu, 30 Jul 2020 13:35:51 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
On 7/30/2020 1:12 PM, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 11:59:42AM -0400, Steven Sistare wrote:
>> On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
>>> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
>>>> This patchset adds support for preserving an anonymous memory range across
>>>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>>>> sharing memory in this manner, as opposed to re-attaching to a named shared
>>>> memory segment, is to ensure it is mapped at the same virtual address in
>>>> the new process as it was in the old one. An intended use for this is to
>>>> preserve guest memory for guests using vfio while qemu exec's an updated
>>>> version of itself. By ensuring the memory is preserved at a fixed address,
>>>> vfio mappings and their associated kernel data structures can remain valid.
>>>> In addition, for the qemu use case, qemu instances that back guest RAM with
>>>> anonymous memory can be updated.
>>> I just realised that something else I'm working on might be a suitable
>>> alternative to this. Apologies for not realising it sooner.
>>> To use this, you'd mshare() the anonymous memory range, essentially
>>> detaching the VMA from the current process's mm_struct and reparenting
>>> it to this new mm_struct, which has an fd referencing it.
>>> Then you call exec(), and the exec'ed task gets to call mmap() on that
>>> new fd to attach the memory range to its own address space.
>> To be suitable for the qemu use case, we need a guarantee that the same VA range
>> is available in the new process, with nothing else mapped there. From your spec,
>> it sounds like the new process could do a series of unrelated mmap's which could
>> overlap the desired va range before the silby mmap(fd) is performed??
> That could happen. eg libc might get its text segment mapped there
> randomly. I believe Khalid was working on a solution for reserving
> memory ranges.
mshare + VA reservation is another possible solution.
Or MADV_DOEXEC alone, which is ready now. I hope we can get back to reviewing that.
>> Also, we need to support updating legacy processes that already created anon segments.
>> We inject code that calls MADV_DOEXEC for such segments.
> Yes, I was assuming you'd inject code that called mshare().
OK, mshare works on existing memory and builds a new vma.
> Actually, since you're injecting code, why do you need the kernel to
> be involved? You can mmap the new executable and any libraries it depends
> upon, set up a new stack and jump to the main() entry point, all without
> calling exec(). I appreciate it'd be a fair amount of code, but it'd all
> be in userspace and you can probably steal / reuse code from ld.so (I'm
> not familiar with the details of how setting up an executable is done).
Duplicating all the work that the kernel and loader do to exec a process would
be error prone, require ongoing maintenance, and be redundant. Better to define
a small kernel extension and leave exec to the kernel.
next prev parent reply other threads:[~2020-07-30 17:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-27 17:11 Anthony Yznaga
2020-07-27 17:07 ` Eric W. Biederman
2020-07-27 18:00 ` Steven Sistare
2020-07-28 13:40 ` Christian Brauner
2020-07-27 17:11 ` [RFC PATCH 1/5] elf: reintroduce using MAP_FIXED_NOREPLACE for elf executable mappings Anthony Yznaga
2020-07-27 17:11 ` [RFC PATCH 2/5] mm: do not assume only the stack vma exists in setup_arg_pages() Anthony Yznaga
2020-07-27 17:11 ` [RFC PATCH 3/5] mm: introduce VM_EXEC_KEEP Anthony Yznaga
2020-07-28 13:38 ` Eric W. Biederman
2020-07-28 17:44 ` Anthony Yznaga
2020-07-29 13:52 ` Kirill A. Shutemov
2020-07-29 23:20 ` Anthony Yznaga
2020-07-27 17:11 ` [RFC PATCH 4/5] exec, elf: require opt-in for accepting preserved mem Anthony Yznaga
2020-07-27 17:11 ` [RFC PATCH 5/5] mm: introduce MADV_DOEXEC Anthony Yznaga
2020-07-28 13:22 ` Kirill Tkhai
2020-07-28 14:06 ` Steven Sistare
2020-07-28 11:34 ` [RFC PATCH 0/5] madvise MADV_DOEXEC Kirill Tkhai
2020-07-28 17:28 ` Anthony Yznaga
2020-07-28 14:23 ` Andy Lutomirski
2020-07-28 14:30 ` Steven Sistare
2020-07-30 15:22 ` Matthew Wilcox
2020-07-30 15:27 ` Christian Brauner
2020-07-30 15:34 ` Matthew Wilcox
2020-07-30 15:54 ` Christian Brauner
2020-07-31 9:12 ` Stefan Hajnoczi
2020-07-30 15:59 ` Steven Sistare
2020-07-30 17:12 ` Matthew Wilcox
2020-07-30 17:35 ` Steven Sistare [this message]
2020-07-30 17:49 ` Matthew Wilcox
2020-07-30 18:27 ` Steven Sistare
2020-07-30 21:58 ` Eric W. Biederman
2020-07-31 14:57 ` Steven Sistare
2020-07-31 15:27 ` Matthew Wilcox
2020-07-31 16:11 ` Steven Sistare
2020-07-31 16:56 ` Jason Gunthorpe
2020-07-31 17:15 ` Steven Sistare
2020-07-31 17:48 ` Jason Gunthorpe
2020-07-31 17:55 ` Steven Sistare
2020-08-03 8:32 ` David Laight
2020-07-31 17:23 ` Matthew Wilcox
2020-08-03 15:28 ` Eric W. Biederman
2020-08-03 15:42 ` James Bottomley
2020-08-03 20:03 ` Steven Sistare
2020-08-04 8:44 ` David Laight
2020-08-04 11:13 ` Matthew Wilcox
2020-08-03 19:29 ` Steven Sistare
2020-07-31 19:41 ` Steven Sistare
2021-07-08 9:52 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2021-07-08 12:48 ` Steven Sistare
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH 0/5] madvise MADV_DOEXEC' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).