* Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > The new Properties Table feature introduced in UEFIv2.5 may split > memory regions that cover PE/COFF memory images into separate code > and data regions. Since these regions only differ in the type (runtime > code vs runtime data) and the permission bits, but not in the memory > type attributes (UC/WC/WT/WB), the spec does not require them to be > aligned to 64 KB. > > Since the relative offset of PE/COFF .text and .data segments cannot > be changed on the fly, this means that we can no longer pad out those > regions to be mappable using 64 KB pages. > Unfortunately, there is no annotation in the UEFI memory map that > identifies data regions that were split off from a code region, so we > must apply this logic to all adjacent runtime regions whose attributes > only differ in the permission bits. > > So instead of rounding each memory region to 64 KB alignment at both > ends, only round down regions that are not directly preceded by another > runtime region with the same type attributes. Since the UEFI spec does > not mandate that the memory map be sorted, this means we also need to > sort it first. So I think this is fundamentally wrong as well, similarly to the related x86 fix. I think for compatibility reasons the whole 'EFI runtime image' should be mapped in a single go, as closely matching the EFI layouts and offsets as possible. We are not talking about gigabytes here, right? Even if technically they are 'separate sections', the x86 bug shows that they aren't. So we should not pretend so on the Linux side either and we should not tear them apart (and then work hard to preserve the interdependencies, some declared, some hidden!). If we allocate the EFI runtime as a single virtual memory block then issues like rounding between sections does not even come up as a problem: we map the original offsets and sizes byte by byte. Thanks, Ingo -- 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
