From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ard Biesheuvel <ardb@kernel.org>, linux-efi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] efistub: arm64: relax 2M alignment again for relocatable kernels
Date: Mon, 26 Jul 2021 14:09:05 +1000 [thread overview]
Message-ID: <2567059e36501744b83c76f4646b073fabb4b1fd.camel@kernel.crashing.org> (raw)
In-Reply-To: <20210722102600.58392-1-ardb@kernel.org>
On Thu, 2021-07-22 at 12:26 +0200, Ard Biesheuvel wrote:
> Commit 82046702e288 ("efi/libstub/arm64: Replace 'preferred' offset with
> alignment check") simplified the way the stub moves the kernel image
> around in memory before booting it, given that a relocatable image does
> not need to be copied to a 2M aligned offset if it was loaded on a 64k
> boundary by EFI.
>
> Commit d32de9130f6c ("efi/arm64: libstub: Deal gracefully with
> EFI_RNG_PROTOCOL failure") inadvertently defeated this logic by
> overriding the value of efi_nokaslr if EFI_RNG_PROTOCOL is not
> available, which was mistaked by the loader logic as an explicit request
> on the part of the user to disable KASLR and any associated relocation
> of an Image not loaded on a 2M boundary.
>
> So let's reinstate this functionality, by capturing the value of
> efi_nokaslr at function entry to choose the minimum alignment.
>
> Fixes: d32de9130f6c ("efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure")
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> This fixes the regression that was discussed in [0], but given that it
> is very likely to break Ben's use case again, I'll sit on it for the
> time being.
The bug is in the version of grub carried by some distros actually. The
stricter alignment forces the stub to reallocate the image in ways that
manages to generally avoid it (but it's all luck). Long story short:
those grubs don't allocate room for the kernel bss (and don't zero it),
thus there's a chance for it to overlap other pre-boot allocations such
as EFI runtime services, the initrd, fdt, whatever else...
So the kernel will break more often with this patch until grub is fixed
in those distros (working on it ...).
Note: If you work on a distro and you carry the grub2 patch that takes
out LoadImage/StartImage from grub-core/loader/arm64/linux.c in favor
of the shim lock protocol, poke me, I have a patch for you :)
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-07-26 4:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 10:26 [PATCH] efistub: arm64: relax 2M alignment again for relocatable kernels Ard Biesheuvel
2021-07-26 4:09 ` Benjamin Herrenschmidt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2567059e36501744b83c76f4646b073fabb4b1fd.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=ardb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).