This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Another way to salvage Annex K and its constraint handler
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Fri, 20 Nov 2015 14:35:19 -0500
- Subject: Re: Another way to salvage Annex K and its constraint handler
- Authentication-results: sourceware.org; auth=none
- References: <564F3982 dot 5020504 at redhat dot com>
On Fri, Nov 20, 2015 at 04:17:22PM +0100, Florian Weimer wrote:
> While looking at __dso_handle and implementing a no-fail wrapper for
> getrandom, it occurred to me that we can implement Annex K in a useful
> fashion, with the constraint handler:
>
> We put the variable that holds the constraint handler address into
> libc_nonshared.a (maybe even as a weak symbol), and pass the address of
> the variable to the actual Annex K implementation functions (with the
> help of inline wrappers, probably). This way, each DSO can install the
> constraint handler it wants. This would remove the need for a
> per-thread constraint handler (which would require constant switching of
> the handler at library boundaries) because libraries know when they
> change constraint handlers and implement suitable locking.
>
> DSOs are out of the scope of C standard, so no standards action is
> needed here.
dlopen is outside the scope, but the behavior of a conforming program
that just happens to be dynamic-linked rather than static-linked is
not outside the scope. You cannot just ignore the constraint handler
set by one function because it happened to be performed from code in a
different DSO. What DSO the code lies in is an implementation detail.
And of course such a "solution" does nothing for static linking
anyway.
Rich