- User Since
- Nov 6 2012, 6:28 AM (428 w, 16 h)
Oct 5 2020
Fine, thanks for explaining!
I might be missing something, but if you release one of the shadow pages to the OS, couldn't it then accidentally use that page for one of the user anonymous mappings, thus breaking DFSan logic?
Jul 17 2020
I don't object against dropping it. I had another case in mind, which turned out to be an actual data race, not something that the compiler pulled out of thin air.
Jul 16 2020
What happens if the load and the store are separated by a barrier atomic load or store? Will they also be combined into a single operation?
Jun 18 2020
Wrapping all variables in the existing tests in PartInit<> doesn't look good.
I believe instead of doing this you need to:
- change existing tests to also run with eager checks, adding expected MSan outputs as needed. Do not scatter PartInit<> across all tests.
- add more tests that use the partinit attribute to cover new functionality.
Jun 16 2020
Jun 10 2020
LGTM assuming allyesconfig builds.
Jun 9 2020
Jun 5 2020
Jun 2 2020
Cool, didn't know that; then the change sure looks reasonable.
May 29 2020
Could you please add an IR test for this?
May 28 2020
Apr 30 2020
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.
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.
fix what I broke
fix what I broke
fix what I broke
Trying to fix the state of the things
I've landed this revision. There are some difficulties with the rest, sorting that out.
Apr 28 2020
Apr 16 2020
Apr 15 2020
Apr 12 2020
I've skimmed through the four patches and they look good. Can you please fix the lint checks?
Mar 26 2020
Yeah, like i said, noinline is insufficient here, and i don't actually
think we currently have the right tool to block any such transform:
Do you think it makes sense to check for noinline before transforming the call into the argument, i.e.:
Mar 25 2020
Mar 24 2020
Mar 3 2020
Feb 19 2020
Hi Florian, Eli et al.,
Oct 23 2019
Oct 21 2019
Adding more people from the original discussion.
Oct 11 2019
Aug 30 2019
Minor comment fix.
Aug 29 2019
Landed r370335, thank you!
Rebased the patch
Aug 26 2019
Aug 7 2019
Added test cases for =x, replaced grep with not
Aug 5 2019
Eli, any other comments?
Jul 30 2019
As a data point, Linus Torvalds suggested that we need a similar feature for GCC so that the "kernel C standard" mandates zero-initialization for locals: https://lkml.org/lkml/2019/7/28/206
Vitaly, what's the current status of these patches? What's your plan on submitting them?
Heads up: this patch reduces the size of the following Android kernel functions:
Test for =X somehow sneaked in - drop it.
Jul 29 2019
Addressed Eli's comments, added a test for a packed struct
Jul 26 2019
Make big_struct() test triple-specific
Fixed comments from Eli and Nick, added tests for unusual struct sizes
Jul 24 2019
Jul 16 2019
Jul 15 2019
Jul 5 2019
Jul 3 2019
Vitaly, can you please rebase the patch?
As far as I can see, you've submitted parts of it already.
(not that I can't resolve the conflicts locally, but keeping it up-to-date may save others some time)
Fixed the test
Jul 2 2019
May 8 2019
Apr 30 2019
Apr 29 2019