OSDev.org

I was implementing multiboot2 in my kernel and was following GRUB multiboot2 spec (https://www.gnu.org/software/grub/manua ... iboot.html).

There's an error in the spec and I spent quite a bit of time debugging my kernel for no reason. I don't know where to report so I thought I may post it here.

Section in question : 3.6.12 Framebuffer info

3.6.12 Framebuffer info
+--------------------+
u32 | type = 8 |
u32 | size |
u64 | framebuffer_addr |
u32 | framebuffer_pitch |
u32 | framebuffer_width |
u32 | framebuffer_height |
u8 | framebuffer_bpp |
u8 | framebuffer_type |
u8 | reserved |
varies | color_info |
+--------------------+

Spec states reserved flag is 8 bit but it should be 16 bit.
When you use 8 bit you get gibberish for color_info.

NOTE : Multiboot2 Example OS given in the same website implements correct struct. it uses 16 bit.

You seem to be correct. Here is the relevant code. I have submitted a bug report with a link to this thread.

If a plain C struct was used for the initial part (with the reserved field at its end), the trailing uint8_t would be padded with another one by the compiler. IOW, this problem is more likely to occur when using assembly or manually/explicitly packing C structs.

Obviously, the Multiboot specifications expect things to be serialized so padding and alignment aren't the issue here. The reason no one noticed this until now is likely that people generally use GRUB's headers rather than implement their own.

Love4Boobies wrote:You seem to be correct. Here is the relevant code. I have submitted a bug report with a link to this thread.

Amazing. Thanks for reporting.

alexfru wrote:If a plain C struct was used for the initial part (with the reserved field at its end), the trailing uint8_t would be padded with another one by the compiler. IOW, this problem is more likely to occur when using assembly or manually/explicitly packing C structs.

Spec can't assume nor rely on that.

https://imgur.com/a/f0CoR6H

@Optimizer601 Hahaha… true.