On 27 September 2015 at 08:03, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:
>
[...]
>> [...] The actual virtual addresses we pick are exactly the same with the two
>> patches.
>
> So I'm NAK-ing this for now:
>
> - The code is it reads today pretends to be an 'allocator'. It is _NOT_ an
> allocator, because all the sections have already been determined by the
> firmware, and, as we just learned the hard way, we do not want to deviate from
> that! There's nothing to 'allocate'!
>
> What these patches seem to implement is an elaborate 'allocator' that ends up
> doing nothing on 'new 64-bit' ...
>
> - The 32-bit and 64-bit and 'old_mmap' asymmetries:
>
> if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
>
> seem fragile and nonsensical. The question is: is it possible for the whole EFI
> image to be larger than a couple of megabytes? If not then 32-bit should just
> mirror the firmware layout as well, and if EFI_OLD_MEMMAP does anything
> differently from this _obvious_ 1:1 mapping of the EFI memory offsets then it's
> not worth keeping as a legacy, because there's just nothing better than
> mirroring the firmware layout.
>
> My suggestion would be to just 1:1 map what the EFI tables describe, modulo the
> single absolute offset by which we shift the whole thing to a single base.
>
> Is there any technical reason why we'd want to deviate from that? Gigabytes of
> tables or gigabytes of holes that 32-bit cannot handle? Firmware that wants an OS
> layout that differs from the firmware layout?
>
The combined EFI_MEMORY_RUNTIME regions could span the entire 1:1
addressable PA space. They usually don't but it is a possibility,
which means 32-bit will not generally be able to support this
approach. For 64-bit ARM, there are some minor complications when the
base of RAM is up very high in physical memory, but we already fixed
that for the boot time ID map and for KVM.
> Also, nobody seems to be asking the obvious hardware compatibility question when
> trying to implement a standard influenced in great part by an entity that is
> partly ignorant of and partly hostile to Linux: how does Windows map the EFI
> sections, under what OSs are these firmware versions tested? I suspect no firmware
> is released that crashes on bootup on all OSs that can run on that hardware,
> right?
>
Interestingly, it was the other way around this time. The engineers
that implemented this feature for EDK2 could not boot Windows 8
anymore, because it supposedly maps the regions in reverse order as
well (and MS too will need to backport a fix that inverts the mapping
order). The engineers also tested Linux/x86, by means of a SUSE
installer image, which booted fine, most likely due to the fact that
it is an older version which still uses the old memmap layout.
My concern with all of this is that this security feature will become
an obscure opt-in feature rather than something UEFIv2.5 firmware
implementations can enable by default.
--
Ard.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html