Re: [edk2-devel][PATCH v1 1/1] MdeModulePkg: DxeCore: Don't Guard Large Runtime Granularity Allocations

["Oliver Smith-Denny" <osde@linux.microsoft.com>]

On 2/15/2024 9:21 AM, Ard Biesheuvel wrote:
> Of the two options you presented in this paragraph, I prefer the one
> where the allocation presented to the caller may not be aligned, but
> the region plus guards is.
> 
> But disabling it entirely for these regions is still perfectly fine
> with me, especially if the remove ACPI reclaim memory from the set.
> Heap guard is a hardening feature, and if the implementation is too
> complex to reason about comfortably, I don't think we can confidently
> rely on it.
> 
> And as far as the OS is concerned: with the MAT, the runtime DXEs are
> mapped in a way where the read-only regions are interleaved with the
> read-write regions, and the holes in between are not mapped at all (at
> least on Linux). IOW, there is some implicit guarding going on
> already.
> 

Looking back at the UEFI spec (section 2.3.6), I see this:

"If a 64KiB physical page contains any 4KiB page with any of the
following types listed below, then all 4KiB pages in the 64KiB page
must use identical ARM Memory Page Attributes" where the following
types are what you listed in the last email.

Then there is a further statement:

"Mixed attribute mappings within a larger page are not allowed."

So this would seem to indicate that pushing the guard pages inside
of the 64KiB would break the spec. Now, I think it could be hidden
and still meet the intent of the spec, which would be that the OS
gets consistent memory attributes reported, but still, the way the
spec is written this would seem to be a violation.

I'll send out a v2 with the type change.

Thanks,
Oliver


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115532): https://edk2.groups.io/g/devel/message/115532
Mute This Topic: https://groups.io/mt/104364784/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-