On Fri, Nov 15, 2013 at 10:36 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Nov 15, 2013 at 10:17:49PM +0400, Konstantin Serebryany wrote:
>> >> Why can't we create the redzone of max(32, alignment) bytes?
>> >
>> > Because it is it is expensive, consider say a 2048 byte aligned variable,
>> Do these happen?
>
> They are supported and some programs do use them, perhaps less often than
> 32-byte and 64-byte aligned vars, but still.
>
>> > So, just do instead:
>> > if (*shadow_bottom == 0) {
>> > while (*reinterpret_cast<u64*>(shadow_bottom) == 0)
>> > shadow_bottom += sizeof(u64);
>> > while (*shadow_bottom == 0) shadow_bottom++;
>> > bottom = SHADOW_TO_MEM (shadow_bottom);
>> > }
>> > ?
>>
>> You suggest to keep some of the shadow, that corresponds to
>> unaddressable memory, zeroed (un-poisoned).
>
> Well, that is what you get if you just use it, __asan_stack_malloc_N gives
> you the whole area cleared, and if you put base not at the very beginning
> of the area, but say 32 bytes from the start, then there will be red zone
> after it. You aren't poisioning shadow from size till end of the stack
> frame upon __asan_stack_malloc_N either.
Well, yes. And we need to fix it, not canonicalize it. Please, let's not rush.
There are many more problems with asan's stack frame layout that I want to fix.
Let me describe them in detail in a bug next week.
For one, the frames are sometimes too large -- we can not deploy
use-after-return widely because of this.
--kcc
>
> Jakub
