Date
1 - 1 of 1
EFI_IMAGE_LOAD_EVENT.ImageLocationInMemory is not useful
Satoshi Tanda
Hi,
It appears that the EFI_IMAGE_LOAD_EVENT.ImageLocationInMemory field can contain practically useless garbage value in some cases. I do not think it is "really" intentional and think it should be fixed.
Some TCG PCR events such as EV_EFI_RUNTIME_SERVICES_DRIVER populate log entries as EFI_IMAGE_LOAD_EVENT, and one of its fields ImageLocationInMemory should contain the base address of the image being measured. As-is, this field may be populated with the address of the temporal buffer as opposed to buffer that is eventually used to execute the image. This makes contents of the ImageLocationInMemory field useless, because the buffer is freed and its contents is destroyed quickly. It would have been substantially more useful if the field contained the address of the final image location, especially for runtime drivers where an operating system could later inspect its contents accordingly to the log.
The problem appears to be that, in CoreLoadImageCommon(), FHand.Source is allocated by GetFileBufferByFilePath() and passed to gSecurity2->FileAuthentication() if the SourceBuffer argument is not supplied. This results in logging the address of the temporal boot-time pool, which is released as soon as the function ends.
https://github.com/tianocore/edk2/blob/e0cb5e1814a67bb12dd476a72d1698350633bcbb/MdeModulePkg/Core/Dxe/Image/Image.c#L1215
It does not explicitly violates the TCG spec, and even if this is fixed, the ImageLocationInMemory value for boot drivers and applications would have been useless for an OS anyway. But, as-is, the field is too often useless because many cases, including with the "load" UEFI shell command, hits the above condition.
Could this be changed in a way to log the image address that is/will be executed, and not a temporal address? I could file a bugzilla case if that's reasonable.
Best,
Satoshi
It appears that the EFI_IMAGE_LOAD_EVENT.ImageLocationInMemory field can contain practically useless garbage value in some cases. I do not think it is "really" intentional and think it should be fixed.
Some TCG PCR events such as EV_EFI_RUNTIME_SERVICES_DRIVER populate log entries as EFI_IMAGE_LOAD_EVENT, and one of its fields ImageLocationInMemory should contain the base address of the image being measured. As-is, this field may be populated with the address of the temporal buffer as opposed to buffer that is eventually used to execute the image. This makes contents of the ImageLocationInMemory field useless, because the buffer is freed and its contents is destroyed quickly. It would have been substantially more useful if the field contained the address of the final image location, especially for runtime drivers where an operating system could later inspect its contents accordingly to the log.
The problem appears to be that, in CoreLoadImageCommon(), FHand.Source is allocated by GetFileBufferByFilePath() and passed to gSecurity2->FileAuthentication() if the SourceBuffer argument is not supplied. This results in logging the address of the temporal boot-time pool, which is released as soon as the function ends.
https://github.com/tianocore/edk2/blob/e0cb5e1814a67bb12dd476a72d1698350633bcbb/MdeModulePkg/Core/Dxe/Image/Image.c#L1215
It does not explicitly violates the TCG spec, and even if this is fixed, the ImageLocationInMemory value for boot drivers and applications would have been useless for an OS anyway. But, as-is, the field is too often useless because many cases, including with the "load" UEFI shell command, hits the above condition.
Could this be changed in a way to log the image address that is/will be executed, and not a temporal address? I could file a bugzilla case if that's reasonable.
Best,
Satoshi