On Tue, Oct 24, 2017 at 12:09:59PM +0100, Ard Biesheuvel wrote: > On 24 October 2017 at 12:05, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxx> wrote: > > On Sun, Oct 22, 2017 at 03:14:57PM +0100, Ard Biesheuvel wrote: > >> ARM shares its EFI stub implementation with arm64, which has some > >> special handling in the virtual remapping code to > >> a) make sure that we can map everything even if the OS executes > >> with 64k page size, and > >> b) make sure that adjacent regions with the same attributes are not > >> reordered or moved apart in memory. > >> > >> The latter is a workaround for a 'feature' that was shortly recommended > >> by UEFI spec v2.5, but deprecated shortly after, due to the fact that > >> it broke many OS installers, including non-Linux ones, and it was never > >> widely implemented for ARM systems. Before implementing b), the arm64 > >> code simply rounded up all regions to 64 KB granularity, but given that > >> that results in moving adjacent regions apart, it had to be refined when > >> b) was implemented. > >> > >> The adjacency check requires a sort() pass, due to the fact that the > >> UEFI spec does not mandate any ordering, and the inclusion of the > >> lib/sort.c code into the ARM EFI stub is causing some trouble with > >> the decompressor build due to the fact that its EXPORT_SYMBOL() call > >> triggers the creation of ksymtab/kcrctab sections. > >> > >> So let's simply do away with the adjacency check for ARM, and simply put > >> all UEFI runtime regions together if they have the same memory attributes. > >> This is guaranteed to work, given that ARM only supports 4 KB pages, > >> and allows us to remove the sort() call entirely. > >> > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > > I guess as this is shared between ARM and ARM64, ARM64 folk should ack > > this before I merge it - can I have an ack from that side please? > > > > Note that the patch does not touch arch/arm64, nor does it affect > arm64, given that the change is a no-op if CONFIG_ARM64=y. That said, > I welcome any acks from the arm64 maintainers, but I don't think they > are actually required here. Looks fine to me: Acked-by: Will Deacon <will.deacon@xxxxxxx> Thanks, Will -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
