On Fri, Sep 18, 2020 at 12:23 PM Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote:
>
> Emulation of the legacy vsyscall page is required by some programs
> built before 2013. Newer programs after 2013 don't use it.
> Disable vsyscall emulation when Control-flow Enforcement (CET) is
> enabled to enhance security.
>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx>
> ---
> v12:
> - Disable vsyscall emulation only when it is attempted (vs. at compile time).
>
> arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
> index 44c33103a955..3196e963e365 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -150,6 +150,15 @@ bool emulate_vsyscall(unsigned long error_code,
>
> WARN_ON_ONCE(address != regs->ip);
>
> +#ifdef CONFIG_X86_INTEL_CET
> + if (current->thread.cet.shstk_size ||
> + current->thread.cet.ibt_enabled) {
> + warn_bad_vsyscall(KERN_INFO, regs,
> + "vsyscall attempted with cet enabled");
> + return false;
> + }
Nope, try again. Having IBT on does *not* mean that every library in
the process knows that we have indirect branch tracking. The legacy
bitmap exists for a reason. Also, I want a way to flag programs as
not using the vsyscall page, but that flag should not be called CET.
And a process with vsyscalls off should not be able to read the
vsyscall page, and /proc/self/maps should be correct.
So you have some choices:
1. Drop this patch and make it work.
2. Add a real per-process vsyscall control. Either make it depend on
vsyscall=xonly and wire it up correctly or actually make it work
correctly with vsyscall=emulate.
NAK to any hacks in this space. Do it right or don't do it at all.
