Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 13 Nov 2017 18:15:57 -0800 | Subject | Re: [PATCH 24/30] x86, kaiser: disable native VSYSCALL |
| |
On Mon, Nov 13, 2017 at 1:07 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote: > On 11/12/2017 07:52 PM, Andy Lutomirski wrote: >> On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen >> <dave.hansen@linux.intel.com> wrote: >>> On 11/10/2017 02:06 PM, Andy Lutomirski wrote: >>>> I have nothing against disabling native. I object to breaking the >>>> weird binary tracing behavior in the emulation mode, especially if >>>> it's tangled up with KAISER. I got all kinds of flak in an earlier >>>> version of the vsyscall emulation patches when I broke that use case. >>>> KAISER may get very widely backported -- let's not make changes that >>>> are already known to break things. >>> >>> Is the thing that broke a "user mode program that actually looks at the >>> vsyscall page"? Like Linus is referring to here: >>> >> Yes. But I disagree with Linus. I think it would be perfectly >> reasonable to enable KAISER and to use a tool like pin on a legacy >> binary from some enterprise distribution. I bet there are lots of >> enterprise distributions that are still supported that use vsyscalls. > > All we need to do in the end here is to re-set _PAGE_USER on the user > page table PGD that is used by the vsyscall page. We should be able to > do that with a line or two of code in kaiser_init(). We can do it > conditionally on when the VDSO is not compile-time disabled. > > I can do this as a follow-on patch, or as the last one in the KAISER > series and leave it up to our esteemed maintainers to decide whether > they want to do it or not. Sound good? > > Are there any userspace tests around that I can use for this, or will I > have to cook something up?
I don't. This old test might be adaptable:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git/tree/test_vsyscall.cc
What you'd want to do is to add a variant that allocates some RWX memory, memcpys the vsyscall page there, and tests that it still works (but only if the vsyscall page worked in the first place).
| |