Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UEFI: correctly handle SetVirtualAddressMap #53

Open
josephlr opened this issue Jun 29, 2020 · 0 comments
Open

UEFI: correctly handle SetVirtualAddressMap #53

josephlr opened this issue Jun 29, 2020 · 0 comments

Comments

@josephlr
Copy link
Contributor

josephlr commented Jun 29, 2020

Right now, SetVirtualAddressMap in the UEFI compatibility layer just adjusts the virtual_start for the MemoryDescriptors returned by the allocator. However, this isn't what we should be doing (if I'm reading the spec correctly).

From the UEFI Specification 2.8 (Errata A), Section 8.4:

  • SetVirtualAddressMap should only be called exactly once during runtime (i.e. after calling ExitBootServices)
  • As Boot Services cannot be active when this is called, we don't need to modify the allocator at all (it won't be used again).
  • We do need to fixup any RuntimeServices code/data so that it can be called w/ non-identity paging.

The basic idea here would be to have separate ELF sections for EfiRuntimeServicesCode and EfiRuntimeServicesData. This would allow the remaining firmware to be unmapped by the OS. The EfiRuntimeServicesCode would need to be built with "relocation-model": "pic".

On a call to SetVirtualAddressMap, the code would then need to also fixup any pointers in static memory to use the new memory mapping. This can be automated by having the linker emit the necessary relocation entries.

EDK2's Implementation: https://github.com/tianocore/edk2/blob/3806e1fd139775610d8f2e7541a916c3a91ad989/MdeModulePkg/Core/RuntimeDxe/Runtime.c#L232

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant