svn commit: r316213 - in head: include lib/libc/include lib/libc/stdlib lib/libc/string lib/libc/tests/stdlib lib/libc/tests/string sys/sys

[Konstantin Belousov]

On Thu, Mar 30, 2017 at 12:51:04AM -0500, Pedro Giffuni wrote:
> Thanks!
> 
> On 30/3/2017 00:00, Konstantin Belousov wrote:
> > On Thu, Mar 30, 2017 at 04:57:26AM +0000, Konstantin Belousov wrote:
> >> Author: kib
> >> Date: Thu Mar 30 04:57:26 2017
> >> New Revision: 316213
> >> URL: https://svnweb.freebsd.org/changeset/base/316213
> >>
> >> Log:
> >>    Implement the memset_s(3) function as specified by the C11 ISO/IEC
> >>    9899:2011 Appendix K 3.7.4.1.
> > Due to (somewhat) controversial nature of the specification, it
> > was agreed that only memset_s() is added, as the function which
> > has real users, even if outside the tree.  There is no plans to
> > add other functions, unless somebody needs them.
> 
> Apple's libc also implemented memset_s() based on some draft
> implementation from NetBSD. This one looks better.
> 
> > If people are curious what are the issues with the Appendix K,
> > please see documents
> > N1173 Rationale for TR 24731 Extensions to the C Library Part I:
> >      Bounds-checking interfaces
> >      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1173.pdf
> > N1967 Field Experience With Annex K
> >      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
> > from the JTC1/SC22/WG14 - C working group.
> >
> >
> 
> Very interesting, thanks! We looked at the spec for a GSoC but ultimately
> we ended up spending a lot more time on FORTIFY_SOURCE and left it aside.
> Ultimately we also left FORTIFY_SOURCE aside but someone has to try such
> experiments :).
> 
> The annex K is basically a Microsoft thing (I think I read about glibc 
> adopting
> it experimentally though). I think it should be useful to have it as an 
> external
> library for portability, not part of libc or even base.
>From the 'Field Experience' document I cited above, it seems that glibc
agressively rejected the proposal to implement it, but I did not investigated
actual mailing lists.

There are self-contained libraries implementation, again judging by the
referenced document.  If you and others strongly prefer this thing to be
thrown out into separate library, I will do that.  OTOH, it is C standard
interfaces, even if optional, and its presence does not affect the runtime,
comparing with other standards-mandated things, like C11 threading.

> 
> I also find interesting that you included an error handler. Perhaps this may
> be useful for other types of runtime bounds checking like the stack 
> canaries,
> safe stack or even the sanitizers. I haven't really looked but we still 
> depend
> on a GCC library (libssp) for the stack protector so we have a can of worms
> there.

My argument pro for providing the settable constraint handler was that
even if implementing a single function from several dozens described by
spec, we should provide all dependencies mandated by spec.  People do not
like the abitily to set the handler, see the referenced doc, but the patch
implements relatively robust mitigation against usual objections.