When you're deploying it for an entire OS, enabling zeroing on init doesn't uncover any bugs in practice while enabling filling with a non-zero value uncovers a lot of them. For whatever reason lots of code has developed unintentional dependencies on uninit data often being zero.
Conversation
Replying to
But in practice it's not zero, except with that clang option or maybe on first time stack reaches that depth. BTW I found some old uclinux minimal shell with such a bug. It blew up with dynamic linking because ldso had already used the stack.
1
Replying to
Overall, uninitialized data usually isn't zero, but it being zero is common enough that there are many cases where it's actually fairly reliably zero so that software somehow develops dependencies on it being zero. The dependency is often that there's one zero byte, not all zero.
1
1
Even after the initial usage of the stack, a fair bit of it is only used for padding or unused space in buffers so it remains zeroed. There's also a lot of code zeroing structures / arrays. It's by far the most pervasive byte. Somehow, software manages to depend on it. *shrug*
1
1
For malloc, I think it must be rare to use the final bytes of certain size classes, so code using C strings manages to depend on having zeroed padding at the end. I feel like a lot of code is written by just fixing all the obvious problems that come up until it appears to work...
1
1
The problems we run into these days are with apps and drivers. Camera and Wi-Fi drivers are both really horrifying and it's not exclusive to a specific brand of them. Atheros and Broadcom both have some really horrifying, awful code and they love uninit data and use-after-free.
1
1
If there is little trust in that code (i.e. use-after-free, use-of-unintialized-variable are likely) why trust the remaining parts of the very same code - the logic most notably?
1
Who said anything about trusting the code? Taking networking as an example it doesn't matter if network drivers of the TCP/IP attack screw up their own security. What matters is that they don't screw up the security of the rest of the system such as giving an attacker RCE.
1
1
Networks are not trusted in the first place. It has nothing to do with trusting the code. RCE is a serious problem even for heavily sandboxed code. These vulnerabilities matter for code without any trust placed in it beyond running it. These are serious problems.
1
1
Software has bugs. The frequency of bugs can be reduced through testing, code review, auditing, static/dynamic analysis tools, etc. but there will still be bugs. Many of them. In a memory unsafe language, many of the common bug classes end up being code execution vulnerabilities.
1
1
Ideally the network stack and device drivers would be written in memory safe languages and implemented in userspace processes but they aren't, and that won't change overnight. Camera drivers are heavily sandboxed and difficult to attack so that's mostly an issue of compatibility.
Would be nice to have robust camera drivers but we have higher priorities. GrapheneOS-specific branch of hardened_malloc keeps a commit with workarounds rebased on master until we get all issues fixed: github.com/GrapheneOS/har. If we supported more devices we'd need more hacks...
1
1
For example, HiKey and HiKey 960 use the Mali GPU driver which has similar memory corruption bugs and we haven't worked around it like this so GrapheneOS has a black screen with them without disabling features.
linaro.org/blog/dragonboa will be much nicer anyway: upstream drivers.
1
Show replies