[Bug sanitizer/85230] asan: false positives in kernel on allocas

["chefmax at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230

chefmax at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chefmax at gcc dot gnu.org

--- Comment #5 from chefmax at gcc dot gnu.org ---
Hi Dmitry,

> I thought that maybe code first deallocates the alloca memory on stack, and only then unpoisons it. But no, it first unpoisons and then restores rsp.

Actually when handling __builtin_stack_restore for alloca, GCC indeed first 
 deallocates the alloca memory on stack, and only then unpoisons it. Take a
look on disasm around shash_update_unaligned crypto/shash.c:104:

  ffffffff8301cc1d:     48 8b 65 b8             mov    -0x48(%rbp),%rsp
  ffffffff8301cc21:     48 8b 7d b0             mov    -0x50(%rbp),%rdi
  ffffffff8301cc25:     48 89 e6                mov    %rsp,%rsi
  ffffffff8301cc28:     e8 f3 b0 b0 fe          callq  ffffffff81b27d20
<__asan_allocas_unpoison>

This is also reflected in GCC source code:

    /* Insert __asan_allocas_unpoison (top, bottom) call after
     __builtin_stack_restore (new_sp) call.
     The pseudocode of this routine should look like this:
       __builtin_stack_restore (new_sp);
       top = last_alloca_addr;
       bot = new_sp;
       __asan_allocas_unpoison (top, bot);
       last_alloca_addr = new_sp;

That's why the issue happens only when interrupt happens inside
__asan_allocas_unpoison call.

So, this looks like an implementation flaw inside GCC, sorry about that :(.
Perhaps we just need to insert all unpoisoning stuff before
__builtin_stack_restore call to resolve the issue.