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

Re: Undefined behavior in glibc

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]
> [5]

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:

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.)

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