This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] libio vtable validation [BZ #20191]
- From: Kees Cook <keescook at chromium dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Yunlian Jiang <yunlian at google dot com>
- Date: Thu, 9 Jun 2016 10:54:52 -0700
- Subject: Re: [PATCH] libio vtable validation [BZ #20191]
- Authentication-results: sourceware.org; auth=none
- References: <a012f7d2-b34f-293f-e8d9-f709432f20ac at redhat dot com>
Looks great! Thanks for the work on this!
-Kees
On Thu, Jun 9, 2016 at 9:33 AM, Florian Weimer <fweimer@redhat.com> wrote:
> This is my latest attempt at vtable verification for libio. It uses Pedro's
> section-based approach to perform the validation of the vtable pointer.
> This is a submission for patch review. I'm reasonably happy with this patch
> and think it is close to something that can be committed.
>
> The relevant ABI analysis is here:
>
> https://sourceware.org/glibc/wiki/LibioVtables
>
> I believe I have added compatibility enablement to all relevant private
> constructor functions.
>
> I verified that the apt-get binary from Debian woody i386 can still open
> files with the new glibc version. (libstdc++ in Debian woody uses libio
> from glibc.)
>
> Conversely, I checked that a few x86_64 binaries would not set the
> IO_accept_foreign_vtables flag when run.
>
> The SHARED case in _IO_vtable_check uses the unprotected _dl_open_hook
> variable, which is somewhat risky. This is essentially another vtable
> pointer which we need to protect anyway; I filed bug 20204 to cover that. I
> will likely have time to implement the minimal solution based on pointer
> mangling (and address bug 20222) before the 2.24 freeze.
>
> At a future point, we need to discuss if we can remove vtable compatibility
> from glibc releases for architectures which did not have a backend in GCC
> 2.95. It seems that GCC 3.0 broke the C++ ABI in a way that is incompatible
> with glibc libio, so only GCC 2.95 could have produced a libstdc++ which
> uses external libio.
>
> Florian
--
Kees Cook
Chrome OS & Brillo Security