On Sat, 28 Dec 2019 at 08:03, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > > > On Dec 28, 2019, at 2:35 PM, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > On Sat, Dec 28, 2019 at 01:29:00PM +0800, Andy Lutomirski wrote: > >> > >>> * The stack must be 16-byte aligned > >> > >> Nope. The asm needs to do this for runtime services. The kernel runs with 8-byte stack alignment. > >> > > 32-bit code is actually only 4-byte aligned in the kernel proper, right? > > Right. By “8” I meant “long”. Sorry. > > > > > Currently, only native 64-bit calls always respect the 16-byte alignment > > requirement, by aligning explicitly in the asm stubs, or after the > > cleanup patches, via the efi bootloader running with 16-byte stack > > alignment. > > > > I think mixed mode might actually be aligned via the asm stub in the > > kernel proper, though it doesn't look like it is in the bootloader > > portion. > > The underlying problem is that gcc doesn’t give us a way to do CALL from asm while preserving more than a single word of alignment. This forces us to compile the kernel proper with reduced alignment. (Also, the generated code is better with reduced alignment.) At runtime, the 64-bit kernel always uses a 16 byte aligned stack when calling into EFI (32 or 64 bit), either by aligning the stack pointer, or by switching to a special stack. On 32-bit kernels, the EFI calls are simply indirect calls generated by the compiler, so there we may enter with a misaligned stack pointer. The EFI stub+decompressor are not built with -mpreferred-stack-boundary=3, and so as long as we ensure that we enter the C code with the proper alignment, the EFI calls will see the correct alignment as well. We currently only do this for native 64-bit boot, though, as 32-bit EFI firmware doesn't seem to require 16-byte alignment in practice.
