Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE
From: David Hildenbrand <hidden>
Date: 2021-08-12 19:24:08
Also in:
linux-api, linux-fsdevel, linux-unionfs, lkml
Possibly related (same subject, not in this thread)
- 2021-09-01 · Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE · David Hildenbrand <hidden>
- 2021-08-27 · Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE · Eric W. Biederman <hidden>
- 2021-08-27 · Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE · Christian Brauner <hidden>
- 2021-08-27 · RE: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE · David Laight <hidden>
- 2021-08-26 · Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE · Eric W. Biederman <hidden>
On 12.08.21 20:10, Linus Torvalds wrote:
On Thu, Aug 12, 2021 at 7:48 AM Eric W. Biederman [off-list ref] wrote:quoted
Given that MAP_PRIVATE for shared libraries is our strategy for handling writes to shared libraries perhaps we just need to use MAP_POPULATE or a new related flag (perhaps MAP_PRIVATE_NOW)No. That would be horrible for the usual bloated GUI libraries. It might help some (dynamic page faults are not cheap either), but it would hurt a lot.
Right, we most certainly don't want to waste system ram / swap space, memory for page tables, and degrade performance just because some corner-case nasty user space could harm itself.
This is definitely a "if you overwrite a system library while it's being used, you get to keep both pieces" situation.
Right, play stupid games, win stupid prices. I agree that if there would be an efficient way to detect+handle such overwrites gracefully, it would be great to have the kernel support that. ETXTBUSY as implemented with this series (but also before this series) is really only a minimalistic approach to help detect some issues regarding the main executable. -- Thanks, David / dhildenb