On Wed, Jan 3, 2018 at 8:07 PM, Hugh Dickins hughd@google.com wrote:
On Wed, Jan 3, 2018 at 5:24 PM, Ben Hutchings ben@decadent.org.uk wrote:
On Wed, 2018-01-03 at 21:11 +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.75 release. There are 39 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
[...]
This seems to be missing a backport of:
commit 85900ea51577e31b186e523c8f4e068c79ecc7d3 Author: Andy Lutomirski luto@kernel.org Date: Tue Dec 12 07:56:42 2017 -0800
x86/pti: Map the vsyscall page if needed
without which, KPTI will break some older user-space.
You're (kind of) right: I did warn Greg of that yesterday, and we were both vaguely hoping that someone else could fill in that blank more quickly than I'd get there.
I doubt it's an actual backport of Andy's 85900ea51577 that's needed - I'd expect his to depend on at least some of the improved infrastructure in 4.15-rc, rather than the old-style kaiser-mapping employed in these backports.
Andrea has a RHEL7 patch for this, and I have a 3.2 patch derived from Andrea's, but neither would be right for 4.9 or 4.4 as is: I think I'm going to have to drop today's priority, and attend to this lacuna tomorrow.
I think what you need to backport is:
"x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy" to get the permission bits right
and maybe the big simplification of kaiser_whatever_its_called_set_pgd(). The latter is going to be a mess if you're still using the old code. Sorry. But even with the crappy old code, kaiser_add_mapping() on the vsyscall page plus the latter _PAGE_USER bit plus the call to the new _PAGE_USER code in "x86/pti: Map the vsyscall page if needed" should do it.
If you skip all this and only get vsyscall emulation working such that vsyscall page *reads* don't work from user mode, you're going to encounter weird problems with programs like "pin". Apparently people use these things.