Implement pattern initialization of memory (excluding the secondary
allocator because it already has predictable memory contents).
Expose both zero and pattern initialization through the C API.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
What should be the behavior of calloc with pattern_fill_contents, should it still be 0 or the pattern?
Out of curiosity, is there any reason to have pattern initialization for heap?
As security researchers note (see the discussion of stack initialization on cfe-dev), zero-initialization has a smaller probability of making existing bugs exploitable.
On the other hand, there is no downside in making the heap zero-initialized, as library features do not introduce language dialects.
Re: calloc behavior, it probably should not return patter-initialized memory even if pattern initialization is enabled.
A lot of code depend on calloc returning zeroes.
compiler-rt/lib/scudo/standalone/combined.h | ||
---|---|---|
401–402 | Please make this 0xAB a constant. |
Pattern initialization for heap can be used as a "poor man's MSan".
Also, it absolutely introduces a language dialect, as in certain code will now reliably work that did not work before. I think security considerations trump that in this case, but it's good to have pattern init as an option, at lease.
I agree on calloc, zeroing memory is in the function's contract.
compiler-rt/lib/scudo/standalone/tests/combined_test.cpp | ||
---|---|---|
140 | s/PatterOrZeroFill/PatternOrZeroFill/ |
Please make this 0xAB a constant.