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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
