This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add strlcpy, strlcat [BZ #178]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 Jun 2017 23:08:08 +0200
- Subject: Re: [PATCH] Add strlcpy, strlcat [BZ #178]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9B943C04B950
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9B943C04B950
- References: <4c1cad2f-97b0-8eb2-199e-1f15f085eeb2@redhat.com> <14ad32aa-df6f-1765-eb1e-e76e2b783640@cs.ucla.edu>
On 06/16/2017 07:09 PM, Paul Eggert wrote:
> On 06/16/2017 03:25 AM, Florian Weimer wrote:
>> I want to start again the discussion to include strlcpy and strlcat in
>> glibc.
>
> Technical progress in other areas has rendered this old proposal even
> less attractive than it was before. My laptop now supports gcc
> -fcheck-pointer-bounds, and Intel CET promises to resist buffer overrun
> attacks more conveniently and systematically. Why not see how these
> approaches play out, and in the meantime let strlcpy's sleeping dogs lie?
Intel MPX in the GNU toolchain is for experiments only. Performance is
worse than Address Sanitizer according to this report:
https://intel-mpx.github.io/performance/
The implementation of memcpy/memmove indeed looks horribly expensive.
By default, the MPX run-time does not terminate the process after
detecting a bounds-checking violation, so it is more of a debugging aid.
MPX uses the same broken approach as Address Sanitizer to use bounds
information along with libc functions: hand-written wrappers. This
means that each time we add a function to glibc (such as explicit_bzero
or reallocarray, or even the C11 function aligned_alloc), we break MPX
support. The range of wrappers offered by the MPX run-time in GCC is
also extremely limited and does not cover important areas such as I/O
functions.
Except for the malloc wrappers in GCC, I could not find *any* memory
allocators with MPX support. The effort to implement them for Python
has stalled:
https://bugs.python.org/issue25300
jemalloc, for example, would need MPX support for its alternative
allocator entry points. APR would need MPX support for its pool
allocator, obstacks would need support, and so on. (TLS works
correctly, though, because GCC uses the type information implied by it.)
Even GCC's own operator new isn't MPX-aware.
And of course, a whole distribution would have to be compiled with MPX
support. I'm not aware of any distribution doing that, or anyone
working on making it happen.
In short, it is fair to say that MPX isn't available today, even though
current silicon may support this.
Does this alter your opinion regarding strlcpy/strlcat?
Thanks,
Florian