Re: [PATCH v3] efi: Request desired alignment via the PE/COFF headers

[Michael Brown <mbrown-OViyBiuKJBuK421+ScFKDQ@public.gmane.org>]

On 18/06/15 23:02, Matt Fleming wrote:
> On Tue, 16 Jun, at 11:37:25AM, Linn Crosetto wrote:
>> I have been reverting this patch as a workaround. The fields need to be changed,
>> but I am not that familiar with the code. Maybe there is a way to use a
>> heuristic to calculate the best values based on init_sz?
>
> Linn, could you please provide some details of the system that you're
> booting this kernel on? EDK2 does not include any checks for this
> alignment requirement, which probably explains why no one else ever
> caught this issue.
>
> I can't think of any way to fix this without simply doing a revert of
> commit aeffc4928ea2 ("x86/efi: Request desired alignment via the PE/COFF
> headers"). Especially since that patch was an optimisation and not a bug
> fix.

I'm pretty sure that patch _is_ a bug fix, not just an optimisation.  It 
looks as though the commit log message was changed from what I 
originally wrote:

    The kernel will align itself to the nearest boundary specified by the
    kernel_alignment field in the bzImage header.  If the kernel is loaded
    to an address which is not sufficiently aligned, it will therefore use
    memory beyond that indicated solely by the init_size field.

    The PE/COFF headers now include a .bss section to describe the
    requirements of the init_size field, but do not currently expose the
    alignment requirement.  Consequently, a kernel loaded via the PE entry
    point may still end up overwriting unexpected areas of memory.

to

    The EFI boot stub goes to great pains to relocate the kernel image to
    an appropriately aligned address, as indicated by the ->kernel_alignment
    field in the bzImage header.  However, for the PE stub entry case, we
    can request that the EFI PE/COFF loader do the work for us.

If the patch is reverted, then I think it will cause undefined behaviour 
on some platforms (which happen to load the kernel to non-preferred 
alignment, and where the memory immediately after the loaded kernel 
happens to be in use for something).

Michael