Re: SetMemorySpaceAttributes with EFI_MEMORY_XP

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

> but then (I think) the DXE_CORE must
have set the same bit in the "supported" bitmask too, when the memory
was added.
that's the point, if my port behaves the same as ArmVirt, it doesn't.
for all memory, capabilities are 8000000000000008 and attributes are
0000000000000000 for unused memory and 0000000000000008 for used
memory.
This seems to confirm what Ard said about the GCD not being altered
for NX permissions.

Thanks
Michael

On Mon, Mar 20, 2017 at 12:06 PM, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/20/17 11:32, Michael Zimmermann wrote:
>> Hi,
>>
>> I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
>> for another platform.
>> So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
>> being enabled?
>> https://github.com/tianocore/edk2/blob/76874be3d411bf8daac051718e20932e0bf97d70/ArmVirtPkg/HighMemDxe/HighMemDxe.c#L95
>> Status = gDS->SetMemorySpaceAttributes (CurBase, CurSize, Attributes);
>>
>> Neither the memory that was added by this Dxe nor the one added
>> automatically by GCD has the EFI_MEMORY_XP capability which causes
>> SetMemorySpaceAttributes to return EFI_UNSUPPORTED.
>
> See commit 413edd470932 ("ArmVirtPkg/HighMemDxe: preserve non-exec
> permissions on newly added regions", 2017-02-28). EFI_MEMORY_XP is only
> requested if EfiConventionalMemory's bit is set in
> PcdDxeNxMemoryProtectionPolicy, but then (I think) the DXE_CORE must
> have set the same bit in the "supported" bitmask too, when the memory
> was added.
>
> Thanks
> Laszlo
>