This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Undefined behavior in glibc
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Dwight Guth <dwight dot guth at runtimeverification dot com>, <libc-alpha at sourceware dot org>, <nd at arm dot com>
- Date: Wed, 10 Feb 2016 11:42:31 +0000
- Subject: Re: Undefined behavior in glibc
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <alpine dot DEB dot 2 dot 10 dot 1601282311351 dot 6102 at digraph dot polyomino dot org dot uk> <20160128234356 dot GH14840 at vapier dot lan> <56AAB6CE dot 8060101 at openwall dot com> <20160129005816 dot GK14840 at vapier dot lan> <56AC16C8 dot 4030202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1601311559210 dot 31071 at digraph dot polyomino dot org dot uk> <56B1F294 dot 5020105 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602031234280 dot 31480 at digraph dot polyomino dot org dot uk> <56B4E8E3 dot 5010308 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602051835320 dot 3446 at digraph dot polyomino dot org dot uk> <56B50010 dot 20202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602052233360 dot 21033 at digraph dot polyomino dot org dot uk> <56BAB213 dot 20102 at openwall dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 10/02/16 03:44, Alexander Cherepanov wrote:
> On 2016-02-05 21:24, Alexander Cherepanov wrote:
>> 1. This rules out all modern hardening/debugging solutions like
>> Valgrind, ASan, Intel MPX, CHERI (don't know if the latter is relevant
>> for glibc).
>
> I guess everybody here is familiar with ASan as used for debugging but perhaps it's worth mentioning that there
> are at least two ongoing projects[1][2] working on full systems using ASan (and, for the second one, UBSan) for
> hardening in production. The specific merits are yet to be assessed but the interest is definitely there.
>
> [4] https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html
> [5] http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/
>
well, address sanitizer was not designed for hardening, there
are ways to fix that, but if such projects start to misuse
asan then it will become harder to fix.
in the glibc context, i think there are only a handful of
cases when the libc has excuse to make assumptions beyond
iso c, and the rest should be clean c code.
but even if the code is fixed, hardening the libc sounds
problematic: on 32bit systems the address space is a scarce
resource and on 64bit systems the shadow map breaks reliable
systems with overcommit off.
(ubsan, i believe, is fine because it works without a runtime,
when it only traps and does not depend on unsafe environment.
unfortunately it has false positives in gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
outside of the libc, most of the problems with the sanitizers
are due to their interactions with the c runtime and dynamic
linker through various unreliable hacks that can break at
any libc update and may provide new attack surfaces.)