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

[Feature Request] ELF loader support for virtual KASLR #138

Open
bencw12 opened this issue Mar 15, 2023 · 0 comments
Open

[Feature Request] ELF loader support for virtual KASLR #138

bencw12 opened this issue Mar 15, 2023 · 0 comments

Comments

@bencw12
Copy link

bencw12 commented Mar 15, 2023

#12 mentions that the kernel_offset argument to loader::elf::Elf::load() effectively does physical KASLR by allowing the kernel to be loaded at an offset from the default at CONFIG_PHYSICAL_START, but users do not have the option to use virtual KASLR when loading an ELF, and miss out on an additional layer of defense against code reuse attacks. KASLR is easily broken by information leaks, but since linux-loader is used in projects like Firecracker where VMs are short-lived, KASLR might be a desirable feature because VMs will be frequently re-randomized.

I was part of a group that published a paper at EuroSys'22 where we implemented KASLR in Firecracker (before it used linux-loader) with little boot time overhead (up to ~4ms for a large kernel config) and ~100 LoC. We also implemented Function Granular KASLR (FG-KASLR) which reduces the impact of an information leak by randomly reordering the functions in the kernel text, meaning that an info leak can only reveal the location of one function rather than the offset of the entire kernel. FG-KASLR has not been added to mainline Linux, but some early preparations for it have been merged upstream. FG-KASLR has much higher overhead than KASLR from our tests (~70ms added to overall boot time) and needs ~1K extra LoC.

FG-KASLR may be a less desirable feature than KASLR due to the overhead and extra code, but users who want KASLR in their VMs as another level of defense would have to resort to using a bzImage which eliminates the benefits of directly loading an ELF. Is support for virtual KASLR a desirable feature for this crate? If so, I'd be happy to provide an implementation.

Thanks!

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