Comment # 6 on bug 1192473 from Ivan Ivanov

(In reply to Takashi Iwai from comment #3)
> (In reply to Christian Gross from comment #2)

> 
> > However, here is the kernel BUG message:
> > 
> > Loading Linux 5.3.18-59.25-default ...
> > Loading initial ramdisk ...
> > EFI stub: Entering in SVC mode with MMU enabled
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > [    0.008983] detected buffer overflow in memcpy
> > [    0.013512] ------------[ cut here ]------------
> > [    0.018109] kernel BUG at ../lib/string.c:1090!
> (snip)
> > [    0.248691] Backtrace:
> > [    0.251138] [<c0da914c>] (fortify_panic) from [<c035fd20>]
> > (socfpga_a10_boot_secondary+0x0/0x10c)
> 
> So here is the problem.  And I guess it's memcpy() call for the
> trampoline, and possibly the compiler got confused.
> 
> As a quirk workaround, you may add #define __NO_FORTIFY before the
> inclusion of header files in arch/arm/mach-socfpga/platsmp.c.
> Maybe there can be a better way to avoid it, though.

I think fortified memcpy in this case works as expected.
secondary_trampoline is declared as a char, while it is actually
start address of the CPU entry code routine. Respectively 
memcpy see the source as pointer to char(1 byte) and copy size of ~40 
bytes, so it panics.

Christian, please, check Matthias test kernel build. There are a few
FORTIFY related changes since 5.3.18 which could help.