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.
12 mentions that the
kernel_offsetargument toloader::elf::Elf::load()effectively does physical KASLR by allowing the kernel to be loaded at an offset from the default atCONFIG_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 sincelinux-loaderis 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!