This is an archive of the discontinued LLVM Phabricator instance.

[sanitizer] Caught global buffer underflow for first variable
Needs RevisionPublic

Authored by condy on May 16 2021, 8:44 PM.

Details

Reviewers
MaskRay
condy
zsrkmyn
eugenis
vitalybuka
Group Reviewers
Restricted Project
Summary

There is no left redzone for global variables, so the underflow of the first variable couldn't be caught.
This patch creates a zero-sized array before the first variable so the underflow of it could be observable.

Diff Detail

Event Timeline

condy created this revision.May 16 2021, 8:44 PM
condy requested review of this revision.May 16 2021, 8:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2021, 8:44 PM
condy edited the summary of this revision. (Show Details)May 16 2021, 8:45 PM
condy added reviewers: zsrkmyn, Restricted Project.
condy edited the summary of this revision. (Show Details)May 17 2021, 12:20 AM
condy updated this revision to Diff 345767.May 17 2021, 12:21 AM

Fix some tests

Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2021, 12:21 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
condy updated this revision to Diff 345777.May 17 2021, 12:52 AM

Fix some tests

condy updated this revision to Diff 345784.May 17 2021, 1:21 AM

Fix all tests

condy updated this revision to Diff 345786.May 17 2021, 1:24 AM

Fix typos

Would you mind to add compiler-rt/test/asan which triggers this one?

You are adding a new global to every translation unit.

  • Private linkage would not allow them to be merged, this can have significant binary size and RAM overhead.
  • There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
  • It is also not referenced from anything, so -gc-sections is likely to kill it.

It looks like this will only work in very limited circumstances.

Would you mind to add compiler-rt/test/asan which triggers this one?

Yes, I will.

condy added a comment.EditedMay 18 2021, 1:30 AM

You are adding a new global to every translation unit.

  • Private linkage would not allow them to be merged, this can have significant binary size and RAM overhead.

Do you suggest linkonce linkage?

  • There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
  • It is also not referenced from anything, so -gc-sections is likely to kill it.

It looks like this will only work in very limited circumstances.

Since it's limited, perhaps making it opt-in is a better choice. -asan-global-underflow or something else.

I think it is too hit-and-miss to add even under a flag. It's just not the right approach - but I also don't know what the right approach would be.

Perhaps adding a small left redzone for all globals and reducing the right redzone to keep the total size under control? This way when most globals are instrumented we get approximately the same amount of redzone between any 2 of them, but also a little on the left of the first one.

I think it is too hit-and-miss to add even under a flag. It's just not the right approach - but I also don't know what the right approach would be.

Perhaps adding a small left redzone for all globals and reducing the right redzone to keep the total size under control? This way when most globals are instrumented we get approximately the same amount of redzone between any 2 of them, but also a little on the left of the first one.

Thanks for explanation, I will try your suggested approach.

vitalybuka requested changes to this revision.May 20 2021, 10:46 AM

So I will hide it from "Ready to Review" list.

This revision now requires changes to proceed.May 20 2021, 10:46 AM
MTC added a subscriber: MTC.Aug 16 2021, 7:28 PM