task: assign each task a unique portion of the kernel address space #588
+218
−139
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
The unit test code causes references to other SVSM logic (such as exception handling) that is only usable when running in the SVSM environment, so to prevent test build errors, it should only be compiled when targeting the SVSM environment. Signed-off-by: Jon Lange <[email protected]>
Much of the logic of task creation is duplicated across user and kernel task creation paths. To simplify code maintainence, these functions can be collapsed into a single function that is capable of both types of task creation. Signed-off-by: Jon Lange <[email protected]>
The address limits of VM ranges may need to be aligned to boundaries other than PML4E boundaries. Lack of alignment is acceptable as long as a single address space is guaranteed not to try to pack multiple VM ranges into a single top-level entry. Signed-off-by: Jon Lange <[email protected]>
There are cases where it is useful to initialize a bitmap allocator with all bits clear (signifying that the bitmap is empty) as well as initializing the allocator with all bits set (signifying that the bitmap is full). Signed-off-by: Jon Lange <[email protected]>
Each task allocates task-specific memory within a per-task virtual address range, which is specific to that task. This means that each task-specific allocation is only accessible within that task. But for the sake of memory safety, where pointers may be passed across tasks, it is important to make sure that no single address is ever valid in more than one task at a time, because that could cause a reference from one task to point to different data when interpreted in a different task. Ensuring unique addresses guarantees that any per-task address that crosses a task boundary will cause a fault instead of referring to the wrong data. Signed-off-by: Jon Lange <[email protected]>
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.
Each task uses a portion of the kernel address space to store task-specific memory, which is only visible in the context of the task that owns it. However, references to task-specific memory can be passed between tasks, and Rust memory safety relies on the principle that any reference (which is captured by its virtual address) must refer to the same underlying data in every context in which that reference is used. This safety principle is defeated if any address is valid in more than one task at a time. Assigning each task a unique portion of the address space ensures that any per-task address that crosses a task boundary will cause a fault instead of referring to the wrong data.