Movatterモバイル変換

This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.

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

• From: Zack Weinberg <zackw at panix dot com>
• To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
• Cc: Siddhesh Poyarekar <siddhesh at gotplt dot org>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
• Date: Fri, 11 Aug 2017 14:06:09 -0400
• Subject: Re: [PATCH 0/2] Multiarch hooks for memcpy variants
• Authentication-results: sourceware.org; auth=none
• References: <DB6PR0801MB20534ED1010DDF1B033821EE83890@DB6PR0801MB2053.eurprd08.prod.outlook.com> <18d2fdf8-ca55-1ded-fa66-3509b3bcf8fe@gotplt.org> <598DF02B.8010607@arm.com>

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 caseswhere the compiler couldn't prove the call was safe - for instance, ifthe size of data copied can vary at runtime.Using _FORTIFY_SOURCE means you accept *some* extra overhead, but wedon't want it to sacrifice *all* machine-specific optimizations.People do things like compiling entire "hardened" distributions withit 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 wouldbe a better maintainability/efficiency tradeoff.  (Of course, I alsothink we shouldn't bypass ifuncs for intra-libc calls.)zw

• Follow-Ups:
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Siddhesh Poyarekar

• References:
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Wilco Dijkstra
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Siddhesh Poyarekar
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Szabolcs Nagy