- User Since
- Oct 3 2012, 3:00 AM (417 w, 5 h)
Mon, Sep 28
Fri, Sep 25
MSan will complain about any undefined bits in a pointer.
We have not seen a false positive caused by this so far, but it sounds like we should relax the requirement. Does it make sense for MSan to allow undef in the lower bits up to the known dereferenceable range of the pointer?
I'm concerned that this may break more things that it will fix.
We may have code relying on initialization done by an memcpy call from under some other interceptor. That's not very reliable, of course, and ideally all such effects should be handled in the top-level interceptor, so this change looks like movement in the right direction.
But please test it thoroughly.
Wed, Sep 23
Documenting this would be a good idea.
You can say something along the lines of:
if a function has a frame pointer, it must point one byte past the end of a record that contains the previous frame pointer in the lower word, and the previous frame return address in the high word.
Tue, Sep 22
Does gcc use the same frame record layout? We've had issues like that with Arm, see GetCanonicFrame. If not, maybe it's not too late to fix?
Mon, Sep 21
Fri, Sep 18
Thu, Sep 17
We really need to do something about this.
How about a change that adds -fdisable-noundef-analysis to every RUN line with %clang?
(-) We are not testing exactly the same mode that is used by the users - but that's already true for many other flags that clang driver passes to -cc1!
(+) Easy to automate, an update script can be provided to downstream users.
(+) Less "magic" than the llvm-lit idea (4 comments above)
Wed, Sep 16
Since this does not affect non-riscv targets, I'll trust your knowledge and test coverage.
This looks reasonable, but I'm not very familiar with the ISA.
A general comment: please change revision summaries to describe what the current patch is doing - this will go into the git commit description.
Tue, Sep 15
Mon, Sep 14
Thu, Sep 10
Where is the implementation of getPlatformTlsSlot?
Aug 27 2020
I wonder if, to be completely correct, we need to rewrite all lifetime calls when extending allocas to 16 bytes in AArch64StackTagging? After all, tag store (llvm.aarch64.stg) is a 16-byte write and it will appear to span beyond the lifetime limits.
Aug 24 2020
Would it be better / easier to apply this to all functions by default, and then opt out some? Which ones would we even need to opt out? I imagine that would only be a handful of "weird" functions like open/openat (for the mode argument), maybe ioctl/fcntl.
Aug 21 2020
Right, the bot has been red since http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/29113, which includes this change.
There has been another change in the same build that broke *everything*, so you likely did not get an actionable message from the buildbot at that time.
Aug 17 2020
I've grabbed a pixel3 test phone from the office. Is there a one-step setup script that I could run and point it at the device? Or would I have to set it up manually ?
I could also do the manual tests where I copy the new bionic libc and this patch's asan-aarch64-android.so. to the phone and run some binaries ... see if they work
Aug 14 2020
LGTM with a nit
This adds future implementation complexity.
LGTM with 1 comment
This change does not enable standalone LSan. It probably should, as a test vehicle if nothing else. See COMPILER_RT_HAS_LSAN.
Aug 13 2020
I think there needs to be something to disable automatic leak detection on exit on older platform, otherwise existing users of ASan will start getting false leak reports.
FYI https://reviews.llvm.org/D85930 moves standalone LSan on Android/aarch64 to the 64-bit allocator, I don't know if you care about this.
LSan-in-ASan is already there.
OK, this seems to be the safe choice then. LGTM.
Aug 12 2020
I wonder if it would pay to selectively apply this for the parts of the shadow that correspond to shared library mappings.
Otherwise we are losing the benefits of huge pages on the heap, which should have a pretty dense shadow.
Aug 10 2020
nocapture on the pointer argument
While we are here, how about setting a few more attributes?
argmemonly, readonly/writeonly, willreturn come to mind.
Aug 7 2020
__libatomic_load might come at the end of the function, with no succeeding BB
Not exactly. It may come at the end of a BB.
Aug 6 2020
Aug 5 2020
I can push this tomorrow unless anyone objects before then.
The problem with "a" is that we do not always know what it means exactly (could be a float), and it's dangerous to dereference the pointer.
Aug 4 2020
Aug 3 2020
Right, that's what the isNoModRef check is for.
Aug 1 2020
Jul 31 2020
Testing this would be pretty hard - we'd need to touch a bunch of memory pages, and then somehow wait for the huge page daemon to merge them (or not).
You want to start scanning at the same point where poisoning is going to be inserted.