Challenge accepted. They aren't because they are defined with ABI/compiler:
- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and different
in 64-bit ABI (8 bytes). Not even sure how the other ABIs got this.
- CB structures like framebuffer struct are not padded to the size compiler likes.
The "packed" attribute would be bit dangerous because then compiler might
complain like "error: taking address of packed member of 'struct cb_framebuffer'
may result in an unaligned pointer value [-Werror=address-of-packed-member]"
Alternatively one could add "pad[2]" member to the end to the fb structure to
fix this, but maybe this will break some payloads which don't check the ->size
of specific tag...
Anyway, hope this illustrates the problem a bit.
Nice catch!
Regardless of the upshot of this it's worth fixing this problem in the coreboot tables implementation.
I'm not very knowledgeable on the topic but don't a lot of CPU ARCH support unaligned pointer access in hardware but it slows things down?
The way you find coreboot table structs is by looping over ->size, since payloads may not know
some tags. So aligning the size up to 8 bytes when generating the coreboot tables should do the trick.
Kind regards
Arthur