Conversation

Replying to

and

I'm not using zero for performance. I explain the choice in github.com/GrapheneOS/har as "Zero-based filling has the least chance of uncovering latent bugs, but also the best chance of mitigating vulnerabilities.". Uncovering bugs also isn't necessarily good for this use case.

github.com

hardened_malloc/README.md at main · GrapheneOS/hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

Replying to

and

I understand, but the discussion was around performance. If we want to keep zero, performance is how it’ll happen. Or, empirical data that zero is better.

Replying to

and

Isn't using it for hardening software in production a valid use case? I would be using zero filling even if the CPU performed worst for zero filling. Using a different value gets complicated because it ideally creates pointers to protected memory and far away from anything valid.

Replying to

and

on 64-bit platforms, repeated 0xAA have that property. However, repeated 0xAA is a pretty large size index, zero isn't. But! In a context like a kernel zero is often a valid pointer sentinel... So what the "right" choice is was pretty hard to agree, and all that was left was perf

Replying to

and

It has that property for 64-bit pointers, but not 32-bit pointers. In a 32-bit process on a 64-bit OS, the entire 32-bit address space is usually accessible. As another common example, the standard Android Runtime uses 32-bit pointers for the managed heaps to reduce memory usage.

Replying to

and

Zero is also simply by far the most conservative and safest value. It's typically what the software is already depending on, since memory starts off zeroed and often stays zeroed or ends up that way. It's the least likely to be a change from how it already was before doing it.

Replying to

and

It's by far the worst option for uncovering bugs, but by far safest option for hardening. It's the only value that I feel comfortable using in production. I'd rather leave the data uninitialized than using any other value. I'd be scared of making more vulnerabilities exploitable.

Replying to

and

It would be difficult to find a real case -ftrivial-auto-var-init=zero made incorrect software less safe, while it makes lots of incorrect software safer from exploitation or other failures. Neither Clang or GCC support hard errors on all uninit use and it's not socially viable.

Replying to

and

I'm not arguing this. I'm stating how I think the long-ass parameter can be removed. Two options: perf, or data.

Replying to

and

I can provide evidence showing that Clang is already written in this language dialect and needs to start passing the switch for correctness, if that counts. I don't think there's going to be a significant performance advantage of zeroing instead of filling with another value.

Replying to

and

In cases where the compiler can see that the data is already being zeroed, it would be removing the redundant zeroing anyway. I can come up with contrived cases where zeroing is faster but I really doubt that it has a substantial performance advantage for most real world usage.

3:32 PM · Jul 15, 2019Twitter Web Client