-
Notifications
You must be signed in to change notification settings - Fork 215
Support position independent code in higher half #285
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
Comments
cc @Freax13 |
I started to look into this in https://github.com/rust-osdev/bootloader/tree/higher-half-pic. Not sure if my approach is right, though. The current error is "the relocation table must end in the elf file". |
Unless I'm missing something, specifying a image base address for a PIC kernel is meaningless because they're supposed to be able to be relocated anywhere. Instead the Lines 96 to 97 in 17ba816
|
I'll take a look at your approach of changing how we calculate the size later today. |
Thanks a lot! This issue is not that urgent, so no hurry.
I guess there are different possible ways to handle this. For example, we could try to default to the image base address if it's still free when ASLR is disabled. Or we could treat it as a fallback for the Either way, we should not panic on PIC kernels with a higher half base address. It should be possible to change the relocation mode without adjusting all addresses in a linker script. |
There is some precedence for treating the base address as the default: glibc used to treat the base address as the preferred address for PIEs when the
Agreed. |
We currently assume that the address given by the |
When a PIC kernel is located in higher half, we currently try to allocate 33554177 entries in the level 4 page table, which of course fails. This is the reason that we currently use the
static
relocation model for our higher half test:bootloader/Cargo.toml
Line 87 in 4e2b8d7
I think the issue is in these lines:
bootloader/common/src/load_kernel.rs
Lines 64 to 75 in 4e2b8d7
Looks like we only consider the end address for the size calculation, without taking the start address into account. I think we should be able to fix this by using the difference between the max and min address as size instead.
The text was updated successfully, but these errors were encountered: