[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [SeaBIOS] [PATCH] smbios: ensure comparison SMBIOS stri
Gabriel L. Somlo
Re: [Qemu-devel] [SeaBIOS] [PATCH] smbios: ensure comparison SMBIOS string can't be paragraph aligned
Tue, 31 Mar 2015 12:37:30 -0400
On Tue, Mar 31, 2015 at 08:49:58AM -0600, Bruce Rogers wrote:
> >>> On 3/30/2015 at 10:02 PM, Kevin O'Connor <address@hidden> 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
> 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...