-
Notifications
You must be signed in to change notification settings - Fork 29
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
ASLR: Lay down the foundations #725
base: main
Are you sure you want to change the base?
Conversation
This change was not tested on macOS ( The change looks artificially bigger than it is because of the x86_64 paging code being moved to a separate file. This is easy for me to undo.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There has been a regression (commit currently unknown) that makes hello_c
not run.
EDIT: ✅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo test new_file_test
(test kernel is written in Rust, should therefore be relocatable) fails:
EDIT: Unrelated to this change, also happens on main
. See #726 (with log).
80d7f57
to
28b8dcf
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #725 +/- ##
==========================================
+ Coverage 68.17% 68.86% +0.68%
==========================================
Files 20 21 +1
Lines 2319 2370 +51
==========================================
+ Hits 1581 1632 +51
Misses 738 738 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent 15 minutes trying to give more context behind the macOS changes on x86_64 and aarch64 to help the review process - where I tried to change the least amount of things possible until the compiler stopped being mad at me (and as a way of double-checking the changes).
The goal is to have this changed merged directly into main
or in a feature branch, so that I can continue working on top of these foundations. Hope this helps.
(EDIT: I marked all of these comments as "resolved" to keep the PR log cleaner.)
3589fe8
to
08bfcfd
Compare
// TODO: guest_address is only taken into account on Linux platforms. | ||
// TODO: Before changing this, fix init_guest_mem in `src/arch/aarch64/mod.rs` | ||
#[cfg(target_os = "linux")] | ||
#[cfg(not(target_arch = "x86_64"))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Remove this #[cfg... mess and replace it with a feature as soon as
https://github.com/hermit-os/uhyve/pull/725/files#r1672908739 is answered.
src/linux/x86_64/kvm_cpu.rs
Outdated
&mut self, | ||
entry_point: u64, | ||
stack_address: u64, | ||
guest_address: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is guest_address
? I think we need some documentation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not clarify this in time, but guest_address
is necessary for setting the registers to their correct values.
This was not done for every architecture and operating system - it was only done on x86_64 Linux and, using guesswork, on x86_64 macOS - however, I had to put it in there everywhere nevertheless, even if it has no effect on some architectures.
src/linux/x86_64/kvm_cpu.rs
Outdated
entry_point: u64, | ||
stack_address: u64, | ||
guest_address: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be GuestPhysicalAddresses, whilst we are on it, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partially resolved, stack_address
and entry_point
possibly unnecessary?
@@ -233,7 +233,7 @@ impl XhyveCpu { | |||
Ok(()) | |||
} | |||
|
|||
fn setup_system_64bit(&mut self) -> Result<(), xhypervisor::Error> { | |||
fn setup_system_64bit(&mut self, guest_address: u64) -> Result<(), xhypervisor::Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a doc comment on what guest_address
is
@@ -219,7 +263,7 @@ impl<VCpuType: VirtualCPU> UhyveVm<VCpuType> { | |||
}; | |||
unsafe { | |||
let raw_boot_info_ptr = | |||
self.mem.host_address.add(BOOT_INFO_ADDR.as_u64() as usize) as *mut RawBootInfo; | |||
self.mem.host_address.add(BOOT_INFO_ADDR_OFFSET as usize) as *mut RawBootInfo; | |||
*raw_boot_info_ptr = RawBootInfo::from(boot_info); | |||
self.boot_info = raw_boot_info_ptr; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the following line (270-271, GitHub won't let me comment) the self.stack_address = ...
check is possibly unsound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some notes on the latest revision which does not fully work...
src/vm.rs
Outdated
@@ -152,6 +231,10 @@ impl<VCpuType: VirtualCPU> UhyveVm<VCpuType> { | |||
self.stack_address | |||
} | |||
|
|||
pub fn guest_address(&self) -> u64 { | |||
self.guest_address.as_u64() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed, and start_address
should be appended.
src/vm.rs
Outdated
let kernel_end_address = kernel_start_address + object.mem_size(); | ||
self.offset = kernel_start_address as u64; | ||
let kernel_end_address = self.start_address.as_u64() as usize + object.mem_size(); | ||
self.offset = self.start_address.as_u64(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, UhyveVm has two entries: self.offset
, self.start_address
, which effectively do the same thing. One of them should be removed, probably.
dc70cc4
to
258784a
Compare
btw, last time i checked, the function i created to generate a random address was pretty trash - this may have to be revised before a merge (or merged with a feature) |
- Move x86_64-related paging code to src/arch/x86_64/paging - Tests: x86_64-related paging tests should use a guest_address that is not 0 - Tests: Move them in separate files, use appropriate 'use' directives - Tests: Use init_guest_mem wrapper in test_virt_to_phys - Fix kernel memory loading - Add guest_address getter in UhyveVm - Change names of constants to clarify their purpose - Use u64 for arch::RAM_START instead of GuestVirtAddr - Remove pagetable_l0 from virt_to_phys function - Various `cargo fmt`-related changes - aarch64: Blindly replace constant names and similar RAM_START change We currently rely on guest_address in MmapMemory to calculate the offsets during the initialization of the VM and when converting virtual addresses to physical addresses. The latter case is intended to be temporary - we should read the value from the CR3 register at a later point, but this is too complex for the time being because of the different architectures. Although this current revision does work with relocatable binaries, it is not making use of this functionality _just_ yet. Fixes hermit-os#719. Co-authored-by: Jonathan <[email protected]>
This will be used by other functions for now, instead of relying on mem.guest_address. guest_address should only be a GuestPhysAddr internally for now, as other functions in places like src/linux/x86_64/kvm_cpu.rs use it.
Removes the start_address entry and uses the existing offset entry instead. Plus some `cargo fmt` changes
not 0
cargo fmt
-related changesWe currently rely on guest_address in MmapMemory to calculate the
offsets during the initialization of the VM and when converting
virtual addresses to physical addresses. The latter case is intended
to be temporary - we should read the value from the CR3 register at
a later point.
Although this current revision does work with relocatable binaries, it
is not making use of this functionality just yet.
Fixes #719.
Fixes #713.