Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 15 November 2017 at 15:48, Laszlo Ersek <lersek@redhat.com> wrote:
> Hi Jian,
>
> On 11/15/17 10:27, Wang, Jian J wrote:
>> I tried this workaround and there're no failure in booting Fedora 26 and Windows
>> server 2016 now. If no objection, I'll merge it into new version of this patch.
>
> I'm not too familiar with the Linux kernel's EFI pieces myself; that's
> why I added Ard and Matt earlier to the thread (when I responded with
> the regression report) -- Ard and Matt maintain EFI in the Linux kernel.
>
> So, if you think there's a bug in Linux (i.e., a mis-interpretation of
> the UEFI spec), can you guys please discuss that together? Below you wrote:
>
> - "I think it must be that the kernel will mark the memory block to be
>    RO/XP/RP memory according to its capabilities but not its current
>    attributes"
>

The UEFI spec does not distinguish between capabilities and
attributes, so how on earth should the OS be able to make this
distinction?

For instance, the UEFI spec defines EFI_MEMORY_RO as

"""
Physical memory protection attribute: The memory region
supports making this memory range read-only by system
hardware.
"""

which is essentially a capability not an attribute. However,
EFI_MEMORY_RO/XP are also used to convey information about the nature
of the *contents* of the memory region, i.e., is it .text, .rodata or
.data/.bss

So given that the OS only has the UEFI memory map to go on, how
exactly should it figure out what these attributes are meant to imply?

> - "there's real gap between UEFI and OS on how to interpret the memory
>    capabilities"
>

Yes. There is also a gap between how GCD and the UEFI memory map
interpret these attributes, which is why nobody bothers to set the
protection capabilities for GCD: it gets copied into the UEFI memory
map, and nobody has a clue how the OS should treat it.

When the [short lived]
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
feature was introduced, it was essentially decided that RO and XP may
be used to annotate the nature of the contents of memory regions,
where code was mapped RO and data mapped XP.

> Why is it wrong for the OS kernel, according to the UEFI spec, to change
> the attributes / mappings of a memory area, as long as it stays
> compliant with the advertised capabilities? How is an OS expected to
> work, upon seeing those new "paging capabilities from UEFI memory map"
> (in Star's words)?
>
> Apparently, it's not just Linux that's confused; see the Win2016 crash
> too. Is the UEFI spec detailed enough on those capabilities? (Recently I
> tried to review the paging capabilities myself in the spec, and I ended
> up totally confused...)
>

I think it is simply impossible at this point to interpret those flags
as attributes, i.e., RO means code that may be mapped read-only, and
XP means data that may be mapped non-executable. Anything beyond that
opens a can of worms that is bound to break stuff all over the place.

-- 
Ard.