From: Florian Weimer <fweimer@redhat.com>
To: "Andy Lutomirski" <luto@kernel.org>
Cc: linux-arch@vger.kernel.org,
"Linux API" <linux-api@vger.kernel.org>,
linux-x86_64@vger.kernel.org,
kernel-hardening@lists.openwall.com, linux-mm@kvack.org,
"the arch/x86 maintainers" <x86@kernel.org>,
musl@lists.openwall.com, <libc-alpha@sourceware.org>,
<linux-kernel@vger.kernel.org>,
"Dave Hansen" <dave.hansen@intel.com>,
"Kees Cook" <keescook@chromium.org>,
Andrei Vagin <avagin@gmail.com>
Subject: Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
Date: Thu, 13 Jan 2022 18:27:15 +0100 [thread overview]
Message-ID: <874k67zguk.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <3a1c8280967b491bf6917a18fbff6c9b52e8df24.1641398395.git.fweimer@redhat.com> (Florian Weimer's message of "Wed, 05 Jan 2022 17:02:48 +0100")
* Florian Weimer:
> Distributions struggle with changing the default for vsyscall
> emulation because it is a clear break of userspace ABI, something
> that should not happen.
>
> The legacy vsyscall interface is supposed to be used by libcs only,
> not by applications. This commit adds a new arch_prctl request,
> ARCH_VSYSCALL_CONTROL, with one argument. If the argument is 0,
> executing vsyscalls will cause the process to terminate. Argument 1
> turns vsyscall back on (this is mostly for a largely theoretical
> CRIU use case).
>
> Newer libcs can use a zero ARCH_VSYSCALL_CONTROL at startup to disable
> vsyscall for the process. Legacy libcs do not perform this call, so
> vsyscall remains enabled for them. This approach should achieves
> backwards compatibility (perfect compatibility if the assumption that
> only libcs use vsyscall is accurate), and it provides full hardening
> for new binaries.
>
> The chosen value of ARCH_VSYSCALL_CONTROL should avoid conflicts
> with other x86-64 arch_prctl requests. The fact that with
> vsyscall=emulate, reading the vsyscall region is still possible
> even after a zero ARCH_VSYSCALL_CONTROL is considered limitation
> in the current implementation and may change in a future kernel
> version.
>
> Future arch_prctls requests commonly used at process startup can imply
> ARCH_VSYSCALL_CONTROL with a zero argument, so that a separate system
> call for disabling vsyscall is avoided.
>
> Signed-off-by: Florian Weimer <fweimer@redhat.com>
> Acked-by: Andrei Vagin <avagin@gmail.com>
> ---
> v3: Remove warning log message. Split out test.
> v2: ARCH_VSYSCALL_CONTROL instead of ARCH_VSYSCALL_LOCKOUT. New tests
> for the toggle behavior. Implement hiding [vsyscall] in
> /proc/PID/maps and test it. Various other test fixes cleanups
> (e.g., fixed missing second argument to gettimeofday).
>
> arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++++-
> arch/x86/include/asm/mmu.h | 6 ++++++
> arch/x86/include/uapi/asm/prctl.h | 2 ++
> arch/x86/kernel/process_64.c | 7 +++++++
> 4 files changed, 21 insertions(+), 1 deletion(-)
Hello,
sorry to bother you again. What can I do to move this forward?
Thanks,
Florian
next prev parent reply other threads:[~2022-01-13 17:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 16:02 [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall Florian Weimer
2022-01-05 16:03 ` [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration Florian Weimer
2022-01-05 16:03 ` [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL) Florian Weimer
2022-01-13 21:31 ` Andy Lutomirski
2022-01-13 21:57 ` Florian Weimer
2022-01-13 21:31 ` [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration Andy Lutomirski
2022-01-13 22:00 ` Florian Weimer
2022-01-14 2:34 ` Andy Lutomirski
2022-01-14 13:28 ` Florian Weimer
2022-01-13 17:27 ` Florian Weimer [this message]
2022-01-13 19:22 ` [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall Boris Lukashev
2022-01-13 21:47 ` Andy Lutomirski
2022-01-14 13:36 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874k67zguk.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=avagin@gmail.com \
--cc=dave.hansen@intel.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-x86_64@vger.kernel.org \
--cc=luto@kernel.org \
--cc=musl@lists.openwall.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.