On Fri, 2022-06-24 at 11:44 +0200, Jan Kiszka wrote:
On 24.06.22 10:53, Heinrich Schuchardt wrote:
On 6/24/22 07:32, Su, Bao Cheng wrote:
During PE hashing, when holes exists between sections, the extra data calculated could be a dupulicated region of the last section.
Such PE image with holes existing between sections may contain the symbol table for the kernel, for example.
The Authenticode_PE spec does not rule how to deal with such scenario, however, other tools such as pesign and sbsign both have the overlapped
Thanks for analyzing differences in hashing.
Above you mention holes between sections. Here you talk about overlapping sections. These two cases are obviously distinct.
Please, provide an accurate description.
Yeah, I also gave that feedback internally already as it left me a bit confused.
Examples (in text form) would be helpful.
There is apparently no good PE dump tooling available, so I try to describe our scenario verbally:
We are generating a unified kernel image, similar to what systemd does, for ARM and ARM64 [1]. The stub has .text and .data sections, and then follows the symbol table (some versions of binutils allow to suppress it, other not, sigh). When appending the actual payload to that (kernel image, command line, initrd, dtbs), those sections are added right after the symbol table, creating an unhashed gap between the last stub section and the first appended one. That unified linux.efi is then signed and should be verifiable and bootable (as it is with EDK2).
I will try to give a more straightforward description, considering below PE image:
## PE Header: @0x00000000 ... ### Section Header 1: ... @0x00000108 : 0x00008000 - SizeOfRawData @0x0000010C : 0x00001000 - PointerToRawData ... ### Section Header 2: ... @0x00000130 : 0x00001C00 - SizeOfRawData @0x00000134 : 0x00009000 - PointerToRawData ... ### Section Header 3: ... @0x00000158 : 0x00001200 - SizeOfRawData @0x0000015C : 0x0000B200 - PointerToRawData ...
From the section headers, the end offset of section 2 is 0x1C00 + 0x9000 = 0xAC00, however, the start offset of the section 3 is 0xB200, there is a `hole` here of size 0x600 bytes. In our case Jan has explained this is the symbol table.
According to PE hasing spec, when finished the parsing of sections, the bytes_hashed should be calculated and compared to the (total PE size - auth size), and if the bytes_hashed is lesser, it means there are extra data need be hashed as well.
According to spec, the offset of the extra data is set to bytes_hashed, this does not cause overlapping for a normal PE image without holes between sections, because the bytes_hashed is equal to the tail of the last section. However, for our case the extra data is the overlapped with the last section or sections, because the bytes_hashed is lesser than the tail of the last section due to the `hole`.
U-Boot currently considers this part of data as overlapped and excludes them from the hashing, however other tools or BLs such as pesign/sbsign/EDK2 do not rule out the overlapped data, the hash result stays consistent among these tools, although the last part is hashed twice indeed.
Baocheng
HTH, Jan
[1] https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md