Re: [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map

["Taylor Beebe" <taylor.d.beebe@gmail.com>]

On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote:
> On 4/17/2024 7:05 AM, Taylor Beebe wrote:
>>
>> On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
>>> Aside from this, I wonder if we can be more aspirational here. These
>>> EfiRuntimeServicesCode regions without attributes set are, if I am
>>> understanding correctly, from loaded images. 
>> These EfiRuntimeServicesCode regions without attributes set are
>> not part of loaded image memory. I think that's what you meant but
>> wanted to clarify.
>
> Are these regions without attributes from image sections that have
> been padded to RUNTIME_PAGE_ALLOCATION_GRANULARITY, i.e. they are
> the pads? Or are we saying we don't know what these regions are
> at this point? It is true in theory someone could just allocate
> an EfiRuntimeServicesCode section.
Good question -- I had not considered the extra padding applied
to these allocations. It could be either. The memory map returned
via GetMemoryMap() will merge descriptors together based on type
so it's possible to mistake an unrelated EfiRuntimeServicesCode
allocation with padding applied to a runtime image memory
allocation if they are contiguous.

When the IMAGE_PROPERTIES_RECORD entry is created, perhaps
it would be best to set the ImageSize field to the padded allocation
size instead of the file size. Is this the difference between virtual size
and raw data size? I recall you recently did this in 
ImagePropertiesRecordLib
for the code size of a new entry.

-Taylor



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