dont modify the bootloader's pagetables #465
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This has the advantage that we don't need to map the memory map into the bootloader's page tables. Up until now, we've assumed that UEFI only maps memory into regions covered by the first PML4 entry, but it turns out that some implementations map the frame buffer into memory mapped by other PML4 entries (this is totally legal, the frame buffer need not be identity mapped). Previously we removed all but the first PML4 entry, so that we can map our own memory there, but it's now clear that this can lead to problems. The solution to this is to not modify the page tables constructed by UEFI and keep all its PML4 entries, but this is problematic because the code constructing the boot info and memory map assumes that it can map them into the same addresses used for the kernel's address space, but UEFI may have already mapped some memory in there. Instead of mapping the boot info and memory map into the bootloader's address space, we now only map them into the kernel's address space. When we want to write to them, we first look up the physical addresses in the kernel's page table and write to the identity mapping. RemoteMemoryRegion implements this. We have some unit tests for constructing the memory map and we want those unit tests to be able to run outside the bootloader, so we can't use RemoteMemoryRegion. To solve this, we introduce a trait MemoryRegionSlice that only requires implementing a method for writing a memory region and implement that slice for MemoryRegionSlice as well as MemoryRegionSlice.
In the future, we'll no longer map the BootInfo into the bootloader's page tables, so we can't/shouldn't create a mutable reference to it. We don't need to use a &'static mut anyway using VirtAddr works just as well.
Modifying the bootloaders page tables by mapping addresses that we don't know for sure are available can lead to all sorts of problems. Simply stop doing that.
We don't need to do this anymore because we no longer modify the bootloader's page tables. This also finally makes it possible to access all memory mapped in by UEFI and not just the memory accessible through the first PML4 entry. Some UEFI implementations map the frame buffer into ranges not accessible through the first PML4 entry.
This was referenced Oct 26, 2024
Merged
|
I just tested both pull requests, they both work great. |
Merged
|
Closed in favor of #466 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Don't modify the bootloader's page tables.
Previously we assumed that the page tables set up by UEFI would only contain relevant mappings in the first PML4 entry, but it turns out that some implementations map the frame buffer into address space ranges mapped by later PML4 entries. As a result, we can no longer just remove all but the first PML4 entry. The problem is that because we've assumed that only the first PML4 entry is used, we've been mapping memory into the address ranges covered by other PML4 entries, but that may no longer work if UEFI already happened to have mapped some memory there.
Fortunately, there's only a single location where we've been mapping memory into the bootloader page tables: We mapped the boot info and memory map into both the bootloader and kernel address spaces so that we can simply create references to them and pass them directly from the bootloader to the kernel. Instead, we now only map memory into the bootloader's address space. When we need to access the memory from the bootloader, we traverse the kernel's page tables to look up the physical address and use the identify mappings to access the physical memory. This is mostly consistent with how we access the kernel's memory in other places.
@Colepng Could you please test that this resolves the issue on your system?
Supersedes #464
Closes #462