[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pmovxprz.fsf@oldenburg.str.redhat.com>
Date: Thu, 13 Jan 2022 22:57:20 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: linux-arch@...r.kernel.org, Linux API <linux-api@...r.kernel.org>,
linux-x86_64@...r.kernel.org, kernel-hardening@...ts.openwall.com,
linux-mm@...ck.org, the arch/x86 maintainers <x86@...nel.org>,
musl@...ts.openwall.com, libc-alpha@...rceware.org,
linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>,
Kees Cook <keescook@...omium.org>,
Andrei Vagin <avagin@...il.com>
Subject: Re: [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
* Andy Lutomirski:
> On 1/5/22 08:03, Florian Weimer wrote:
>> Signed-off-by: Florian Weimer <fweimer@...hat.com>
>
> This seems like a respectable test case, but why does it work so hard
> to avoid using libc?
Back when this was still a true lockout and not a toggle, it was
necessary to bypass the startup code, so that the test still works once
the (g)libc startup starts activating the lockout. The /proc mounting
is there to support running as init in a VM (which makes development so
much easier).
I could ditch the /proc mounting, perform some limited data gathering in
a pre-_start routine, undo a potential lockout before the tests, and
then use libc functions for the actual test. It would probably be a bit
less code (printf is nice), but I'd probably have to use direct system
calls for the early data gathering anyway, so those parts would still be
there.
Thanks,
Florian
Powered by blists - more mailing lists