Remapping UEFI runtime services via set_virtual_address_map() breaks the SystemTable struct

[foxcob]

When remapping the UEFI runtime code and data memory regions, if the the region containing the UEFI SystemTable is remapped, the existing SystemTable struct will continue to keep a pointer to the old physical location and likely result in a crash if accessed again.

A method needs to be provided to construct a new SystemTable from the existing with a new internal virtual address.

The way this makes the most sense to me is to pass the newly translated address into the call to set_virtual_address_map() and have set_virtual_adddress_map return a new SystemTable. Maybe it should consume the existing table as well.

A separate method could also be provided. As it is now, no public method exists for creating a new SystemTable and so the runtime services are useless if the UEFI memory regions are relocated.

[GabrielMajeri]

How about the following fix:

• Hide the set_virtual_address_map method from RuntimeServices and make it a method on SystemTable.
• Have it take the self: SystemTable object by move, to ensure the calling code has no other references to it.
• Have it receive the new virtual address of the system table.
• Update the internal reference to the SystemTableImpl
• Return the new SystemTable object.

Are there any other references that have to be updated?

[foxcob]

I think that's the only reference that needs manual updating. From what I can tell, the UEFI firmware updates all of the other addresses in the internal table during the call.

This solution seems good. Consuming the existing table is probably the safest thing to do to guarantee there are no accesses to it after the call.