This is the mail archive of the glibc-bugs@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]

[Bug libc/21198] malloc, free, _start, _exit etc should automatically zero memory


https://sourceware.org/bugzilla/show_bug.cgi?id=21198

--- Comment #3 from infinity0 at pwned dot gg ---
The point of this ticket is not about the *possibility* of doing this, but
about reducing the *cost* of doing this across the whole software ecosystem.

If glibc sets this as a default option, this would greatly reduce the cost of
doing this for everyone, down to zero.

If glibc hides this behind a -D_FORTIFY_SOURCE flag, OS distributions can
experiment with setting this globally, instead of every single project or user
doing it. Or, projects that prefer to distribute their own binaries can also
experiment with this flag themselves. Globally, the total sum cost of everyone
doing this is greatly reduced.

It's 2017 - more secure settings should be the default. I have been told about
some special cases when this might be a significant performance issue, but
these special cases (who already need to think about malloc specifics) should
be the ones having to set non-default more-risky mallopt options.

Furthermore, _FORTIFY_SOURCE has historically been a good mechanism for
distributions to improve the security of *all* of their programs, and it seems
a good fit for this issue as well. If every user or program writer had to set
an envvar or program option, instead of _FORTIFY_SOURCE being set automatically
on a whole-distribution level by Red Hat, Debian, and other distros, then
nearly nobody would be doing it even if "it's possible".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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