This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/2] Multiarch hooks for memcpy variants
Zack Weinberg wrote:
> On Mon, Aug 14, 2017 at 9:22 AM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> > I still can't see any reason to even support these entry points in GLIBC, let
> > alone optimize them using ifuncs.
> They are already exported by libc.so.6 so we are stuck with them, but
> what if we demote the copies in libc.so.6 to compat symbols and shove
> the "real" versions into libc_nonshared.a? Then their calls to their
> "normal" counterparts will naturally go through the PLT and hit the
> "proper" ifuncs, without any messing around with assembly language.
But that means we still need to provide non-compat _chk entry points
indefinitely. See below for an alternative option that removes them now.
> Also it took something like 20 years to get all the counterproductive
> inline functions out of string.h, let's not be putting them back now.
> I _like_ the idea of inlining the runtime check done by the _chk entry
> points, but it should be done in the compiler, and the compiler might
> still prefer to call the _chk entry points when optimizing for size.
They are already inline functions that expand into GCC builtins which result
in calls to the _chk variants. The current implementation is a hopeless hack
and only checks a small percentage of the cases that could be checked
(I tried char arr[N]; memcpy (arr+1, p, n) and this is not checked...).
We can and should implement much more accurate bounds checking in GCC.
The checks would always be inlined so the overhead is low and the normal
ifunc is called. This works with any library, not just GLIBC.
When building with an old GCC we could simply inline in the headers to stop
people adding ifuncs for this flawed "security" feature. That way the existing
symbols can immediately become compat symbols and all the _chk entry points
and ifuncs can be completely removed.