- User Since
- Oct 3 2012, 3:00 AM (284 w, 4 d)
Fri, Mar 16
@pcc, @kcc I'm not sure about this. It adds one extra instruction per function, which is not exactly free. Do you have any estimates on how much additional protection does it provide? My gut feeling is that it would be only a minor speed bump in most cases.
Are you going to provide a zero page for ignores loads and a scratch page for ignored stores? Is it valid to use an isStore pointer for loading? If not, then load-modify-store operations will have to request two pointers and expect them to be different?
What kind of code will this basic block contain? Can it be created later, at the end of instrumentation pass?
Wed, Mar 14
Mon, Mar 12
Fri, Mar 9
Wed, Mar 7
Fri, Mar 2
OK, sure, as long as it's under if(FreeBSD).
Mon, Feb 26
Do we need to change other sanitizers?
Fri, Feb 23
Could you reliably trigger a check failure, with a wild free for example?
I'm thinking a test would be nice.
A constructor would also mitigate the dlopen issue (see the comment before the interceptor). Not that we've seen this issue in the wild.
Thu, Feb 22
What kind of linkage issue?
I mean, in my view of the world, it is completely fine to build a static library with -fPIE and then link it to an executable. I'd like to understand what is wrong with that on FreeBSD.
What is the problem with -fPIE? Is it not supported to link PIE and PIC objects in one binary?
Wed, Feb 21
I had to fix userspace callbacks - they were still doing hlt with 0x100 instead of brk with 0x900.
That's great, I'm still testing it in combination with https://reviews.llvm.org/D42473. It should simply go away when I do git pull.
I'll take care of it.
Looks great, thank you!
I can land it for you.
You can pass multiple repositories as arguments to svn diff, or upload a separate revision, or use git monorepo.
Feb 14 2018
Andrey, do you mind switching userspace to brk as well? You'd need to change the decoding in hwasan_linux.cc as well, but it could be even less work than writing a kernel-only lit test.
Feb 12 2018
LGTM, thank you!
Feb 9 2018
LGTM with a test.
Please don't copy all the tests for different hlt# values, just one would be enough to capture the difference in 0x900.
Feb 8 2018
add a comment
Feb 5 2018
Feb 2 2018
Jan 31 2018
I've reverted your commit in r323929.
It miscompiles the following program on armv7-linux-android:
Jan 29 2018
Jan 25 2018
Jan 24 2018
Oh, sorry, I did not notice that you said "unset".
Maybe. On the other hand, LD_LIBRARY_PATH could be set for a reason other than libc++. It sounds like whether we do it or not, we may break some users.
Unless I'm missing something, it should not be necessary if we add -Wl,-rpath flags to the right %clang substitutions.
Right. That's why LD_LIBRARY_PATH is evil, as are environment variables in general.
IMHO the right way is to set DT_RUNPATH for each executable that wants non-standard libraries. That includes your host compiler.
Jan 23 2018
I'm not sure about this. Reverting to an old, deprecated feature is rarely the answer.
For example, Android does not support DT_RPATH at all.
fix one test
Ah, ok. It's strange to have different suffixes for error vs access callbacks. Is that for GCC compatibility?
Yes, the same as asan.
Please fix hwasan as well.
Jan 22 2018
removed one flag, fixed a condition, improved the test
Remove -customcc code. Added inlining logic.
Jan 19 2018
add one more reason
Jan 17 2018
Jan 16 2018
An attempt to inline the safestack accessor function.