Messages in this thread | | | From | Keno Fischer <> | Date | Mon, 29 May 2017 19:08:30 -0400 | Subject | Yes, people use FOLL_FORCE ;) |
| |
Hi Linus et al.,
In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed punch through semantics of /proc/<pid>/mem. We used these semantics as a hardening mechanism in the julia JIT. By opening /proc/self/mem and using these semantics, we could avoid needing RWX pages, or a dual mapping approach. We do have fallbacks to these other methods (though getting EIO here actually causes an assert in released versions - we'll updated that to make sure to take the fall back in that case). Nevertheless the /proc/self/mem approach was our favored approach because it a) Required an attacker to be able to execute syscalls which is a taller order than getting memory write and b) didn't double the virtual address space requirements (as a dual mapping approach would).
Now, while we're probably fine with using the fallbacks, I know there's others that rely on this behavior as well (cc'ing Robert O'Callahan of the rr project for which this change will result in significant performance degradation). Also, judging by who complained last time FOLL_FORCE was broken, I suspect the Wine people are relying on this as well. Frankly, I'm a bit surprised that this change was made in the first place. Making a userspace-breaking change on mainline and seeing if anybody complains doesn't seem like the ideal way to find out if features are used.
As I said, personally we can patch our software and deal with this, but I think a change like this deserves a bit wider discussion, so may I suggest a revert of this change for the time being? Maybe there can be a syslog warning such that people who use it will notice and have their say on the mailing list.
Thanks, Keno
| |