> 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

Reply via email to