On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen <[email protected]> wrote: > > From: Dave Hansen <[email protected]> > > The VSYSCALL page is mapped by kernel page tables at a kernel address. > It is troublesome to support with KAISER in place, so disable the > native case. > > Also add some help text about how KAISER might affect the emulation > case as well.
Can you re-explain why this is helpful? Also, I'm about to send patches that may cause a rethinking of how KAISER handles the fixmap. --Andy > > Signed-off-by: Dave Hansen <[email protected]> > Cc: Moritz Lipp <[email protected]> > Cc: Daniel Gruss <[email protected]> > Cc: Michael Schwarz <[email protected]> > Cc: Richard Fellner <[email protected]> > Cc: Andy Lutomirski <[email protected]> > Cc: Linus Torvalds <[email protected]> > Cc: Kees Cook <[email protected]> > Cc: Hugh Dickins <[email protected]> > Cc: [email protected] > > --- > > b/arch/x86/Kconfig | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff -puN arch/x86/Kconfig~kaiser-no-vsyscall arch/x86/Kconfig > --- a/arch/x86/Kconfig~kaiser-no-vsyscall 2017-11-08 10:45:39.157681370 > -0800 > +++ b/arch/x86/Kconfig 2017-11-08 10:45:39.162681370 -0800 > @@ -2231,6 +2231,9 @@ choice > > config LEGACY_VSYSCALL_NATIVE > bool "Native" > + # The VSYSCALL page comes from the kernel page tables > + # and is not available when KAISER is enabled. > + depends on ! KAISER > help > Actual executable code is located in the fixed vsyscall > address mapping, implementing time() efficiently. Since > @@ -2248,6 +2251,11 @@ choice > exploits. This configuration is recommended when userspace > still uses the vsyscall area. > > + When KAISER is enabled, the vsyscall area will become > + unreadable. This emulation option still works, but KAISER > + will make it harder to do things like trace code using the > + emulation. > + > config LEGACY_VSYSCALL_NONE > bool "None" > help > _
