[PATCH 5/X] [libsanitizer][mid-end] Introduce stack variable handling for HWASAN
Matthew Malcomson
Matthew.Malcomson@arm.com
Wed Nov 20 14:42:00 GMT 2019
Hi Martin,
Thanks for the review,
I'll get working on your comments now, but since I really enjoyed
finding this bug in ./configure when I hit it I thought I'd answer this
right away.
On 20/11/2019 14:02, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>>
>> diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk
>> index
>> 4f60bed3fd6e98b47a3a38aea6eba2a7c320da25..91989f4bb1db6ccff564383777757b896645e541
>> 100644
>> --- a/config/bootstrap-hwasan.mk
>> +++ b/config/bootstrap-hwasan.mk
>> @@ -1,7 +1,11 @@
>> # This option enables -fsanitize=hwaddress for stage2 and stage3.
>> +# We need to disable random frame tags for bootstrap since the
>> autoconf check
>> +# for which direction the stack is growing has UB that a random frame
>> tag
>> +# breaks. Running with a random frame tag gives approx. 50% chance of
>> +# bootstrap comparison diff in libiberty/alloca.c.
>
> Here I would like to see what's exactly the problem. I would expect ASAN
> will
> have exactly the same problem? Can you please isolate it and file a bug.
> I bet
> a configure script should not expose an undefined behavior.
>
The configure problem is this snippet below:
find_stack_direction ()
{
static char *addr = 0;
auto char dummy;
if (addr == 0)
{
addr = &dummy;
return find_stack_direction ();
}
else
return (&dummy > addr) ? 1 : -1;
}
main ()
{
exit (find_stack_direction() < 0);
}
configure uses this to determine the direction that the stack grows.
`find_stack_direction` compares the address of two different objects and
uses that to make a decision.
With HWASAN random frame tags the answer to the comparison is mostly
determined by what random tag was assigned to the object in each frame,
rather than the memory layout of the stack -- which means this configure
test program can end up getting different answers on different runs.
This is not a problem for ASAN since ASAN does not store tags in the
pointers of variables.
You're right -- I should file a bug on that for configure.
For reference the UB clause in the standard is 6.5.8 #5 (relational
operators) where there's a sentence at the end saying "In all other
cases, the behaviour is undefined". Essentially, this program is
comparing the address of two different objects on the stack, and that's
not allowed.
More information about the Gcc-patches
mailing list