[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8652E0AC-BE79-418E-BDA2-DCEFFEC45932@sempervictus.com>
Date: Thu, 13 Jan 2022 14:22:48 -0500
From: Boris Lukashev <blukashev@...pervictus.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
Publish an LPE abusing the problem - Linus can move fast if there is bad PR to be had from not doing so. Unfortunately security in upstream tends to be a reactive function.
-Boris
On January 13, 2022 12:27:15 PM EST, Florian Weimer <fweimer@...hat.com> wrote:
>* 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@...hat.com>
>> Acked-by: Andrei Vagin <avagin@...il.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
