On Tue, Mar 31, 2015 at 08:49:58AM -0600, Bruce Rogers wrote:
On 3/30/2015 at 10:02 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Mon, Mar 30, 2015 at 05:06:30PM -0600, Bruce Rogers wrote:
The SMBIOS anchor string _SM_ is stored within SeaBIOS to validate an SMBIOS entry point structure. There is the possibility (observed) that this comparison string ends up paragraph aligned and mistakenly found during a search for the real SMBIOS entry point. Ensure it will never end up on a paragraph boundary by storing it at odd alignment.
Thanks.
What OS was this on? It's really an OS bug as the OS needs to check both the signature and the checksum.
My preferred approach to addressing this would be to turn p->anchor_string into a u32 and do an integer compare instead of a string compare. Although technically this can lead to the same potential issue, in practice it should not happen because SeaBIOS' init code is relocated out of the f-segment during startup (while static strings are generally not).
-Kevin
This was actually flagged by the QEMU make check test in tests/bios-tables-test.c, where the code has asserts based on the first find of the _SM_ string found on a paragraph boundary in the f segment. It assumes that the string found is sufficient to identify the smbios entry point structure.
I read in http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pd... where there are number of steps needed to verify the entry-point, beyond finding the anchor string. So I assume that the make check test needs to be fixed.
But I wonder if bios creators are also supposed to ensure that there is no such string findable on a paragraph boundary so as to avoid any potential confusion? I don't have expereince writing bios's so I am only guessing at that.
I guess on physical hardware that would be mitigated by the BIOS's .rodata (or whatever the equivalent thing is called in BIOS-speak) NOT falling within 0xf0000..0xfffff :)
If there's no way to guarantee that with SeaBIOS, I suppose the qemu test could be rewritten to account for the possibility of "false positive" signatures...
--Gabriel