> So the idea is, look at the target area, > - determine if the remaining size in that blob (the pointed-to blob) > could still contain an ACPI table header, > - if so, check the presumed "length" field in that header, and see if > it's self-consistent (ie. >= sizeof(header), and <= remaining size in > blob) > - if so, run a checksum on the bytes that presumably constitute the > ACPI table > - if it sums to zero, we attempt to install the target area with > EFI_ACPI_TABLE_PROTOCOL, otherwise we leave it alone.
This is clever. But maybe it is even simpler to do look at the few tables that contain pointers to other tables (RSDP -> RSDT, RSDT -> FADT and more, FADT -> DSDT, FADT -> FACS) and pass those to EFI_ACPI_TABLE_PROTOCOL. Of course the _other_ clever, and IMHO more important, part of your scheme... > Now, EFI_ACPI_TABLE_PROTOCOL makes deep copies of the tables it gets, > but we'll leave the entire forest that we've build during the first > processing in place. Why? Because this way all the stuff that *didn't* > look like an ACPI table during the procedure above will remain in place, > and the pointers *to* them will remain valid, in those ACPI table copies > that EFI_ACPI_TABLE_PROTOCOL creates. ... i.e. this one, remains unchanged. > This approach would leak a few pages of AcpiNVS memory, and it has a > slight chance to call EFI_ACPI_TABLE_PROTOCOL.InstallTable() with > garbage (that has a valid-looking Length field and checksums to zero). > But it would remain compatible with EFI_ACPI_TABLE_PROTOCOL, and it > wouldn't miss anything from QEMU's payload that in fact *is* an ACPI table. > > Deal? As far as the leak is concerned, definitely. For the other part, whatever you think is simpler will do for me. Paolo ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel