This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/2] Multiarch hooks for memcpy variants


On Fri, Aug 11, 2017 at 1:58 PM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> as far as i understand *_chk calls are only generated when
> compiling with -D_FORTIFY_SOURCE=* and most of these checks
> could be inlined by the compiler (i.e. there is no need
> for runtime support in principle).

Calls to _chk functions that survive in the executable are for cases
where the compiler couldn't prove the call was safe - for instance, if
the size of data copied can vary at runtime.

Using _FORTIFY_SOURCE means you accept *some* extra overhead, but we
don't want it to sacrifice *all* machine-specific optimizations.
People do things like compiling entire "hardened" distributions with
it on.

> may be the generic __memcpy_chk should call the ifunced
> memcpy so it goes through an extra plt indirection, but
> at least less target specific code is needed.

I was thinking of making this suggestion myself.  I think that would
be a better maintainability/efficiency tradeoff.  (Of course, I also
think we shouldn't bypass ifuncs for intra-libc calls.)

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]