Follow @Openwall on Twitter for new release announcements and other news
[<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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.