mailing list of musl libc
 help / color / mirror / code / Atom feed
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,
	 "Dave Hansen via Libc-alpha" <libc-alpha@sourceware.org>,
	 "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	 "Dave Hansen" <dave.hansen@intel.com>,
	"Kees Cook" <keescook@chromium.org>
Subject: [musl] Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
Date: Fri, 26 Nov 2021 21:24:16 +0100	[thread overview]
Message-ID: <87lf1ais27.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <4728eeae-8f1b-4541-b05a-4a0f35a459f7@www.fastmail.com> (Andy Lutomirski's message of "Fri, 26 Nov 2021 10:58:26 -0800")

* Andy Lutomirski:

> On Fri, Nov 26, 2021, at 5:47 AM, Florian Weimer wrote:
>> 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_LOCKOUT.  Newer libcs can adopt this request to signal
>> to the kernel that the process does not need vsyscall emulation.
>> The kernel can then disable it for the remaining lifetime of 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.
>
> Why is a lockout needed instead of just a toggle?  By the time an
> attacker can issue prctls, an emulated vsyscall seems like a pretty
> minor exploit technique.  And programs that load legacy modules or
> instrument other programs might need to re-enable them.

For glibc, I plan to add an environment variable to disable the lockout.
There's no ELF markup that would allow us to do this during dlopen.
(And after this change, you can run an old distribution in a chroot
for legacy software, something that the userspace ABI break prevents.)

If it can be disabled, people will definitely say, “we get more complete
hardening if we break old userspace”.  I want to avoid that.  (People
will say that anyway because there's this fairly large window of libcs
that don't use vsyscalls anymore, but have not been patched yet to do
the lockout.)

Maybe the lockout also simplifies the implementation?

> Also, the interaction with emulate mode is somewhat complex. For now,
> let’s support this in xonly mode only. A complete implementation will
> require nontrivial mm work.  I had that implemented pre-KPTI, but KPTI
> made it more complicated.

I admit I only looked at the code in emulate_vsyscall.  It has code that
seems to deal with faults not due to instruction fetch, and also checks
for vsyscall=emulate mode.  But it seems that we don't get to this point
for reads in vsyscall=emulate mode, presumably because the page is
already mapped?

> Finally, /proc/self/maps should be wired up via the gate_area code.

Should the "[vsyscall]" string change to something else if execution is
disabled?

Thanks,
Florian


  reply	other threads:[~2021-11-26 20:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 13:47 [musl] " Florian Weimer
2021-11-26 18:58 ` [musl] " Andy Lutomirski
2021-11-26 20:24   ` Florian Weimer [this message]
2021-11-26 22:53     ` Andy Lutomirski
2021-11-26 23:18       ` Florian Weimer
2021-11-28  4:45         ` Andy Lutomirski
2021-12-16 18:31           ` 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=87lf1ais27.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).