Messages in this thread | | | From | Andy Lutomirski <> | Date | Sun, 12 Nov 2017 19:52:34 -0800 | Subject | Re: [PATCH 24/30] x86, kaiser: disable native VSYSCALL |
| |
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: >> On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen >> <dave.hansen@linux.intel.com> wrote: >>> On 11/09/2017 06:25 PM, Andy Lutomirski wrote: >>>> Here are two proposals to address this without breaking vsyscalls. >>>> >>>> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on high >>>> mappings but, optionally, warn if you see _PAGE_USER on any address >>>> that isn't the vsyscall page. >>>> >>>> 2. Ignore _PAGE_USER entirely and just mark the EFI mm as special so >>>> KAISER doesn't muck with it. >>> >>> These are totally doable. But, what's the big deal with breaking native >>> vsyscall? We can still do the emulation so nothing breaks: it is just slow. >> >> 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.
| |