[Feature Request] ELF loader support for physical/virtual KASLR

[bysui]

Feature Request

Currently, the x86 kernel is loaded into a fixed physical address and runs at a fixed virtual address. Physical/Virtual KASLR is not available, as it is only handled for bzImage during decompression, missing out on an additional layer of defense against code reuse attacks. KASLR is easily broken by information leaks, but since Firecracker uses short-lived VMs, KASLR might be a desirable feature because the VMs will be frequently re-randomized.

Describe the desired solution

• Physical KASLR
  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. So we only need to provide a kernel_offset that is aligned to CONFIG_PHYSICAL_ALIGNED.
  For PVH entry, the current code in linux_loader doesn't support physical KASLR. If we provide a kernel_offset, it will choose to use the Linux 64-bit boot protocol. However, in the Linux kernel, physical KASLR for PVH entry has been allowed since commit 47ffe0578aee45fed3a06d5dcff76cdebb303163 which introduced a new PVH ELF note that imposes the relocation range. I can change the handling in linux_loader to adapt to this.

• Virtual KASLR
  There is no available function in linux_loader for now. However, it is easily to implemented, all we need is the relocation information for kernel. In x86 kernel, there is a vmlinux.relocs file which contains all relocation information needed, so what we need is to read it and perform relocation like handle_relocations() in arch/x86/boot/compressed/misc.c. The only discussion is where to implement it: in Firecracker or linux_loader.

Describe possible alternatives

As for virtual KASLR, I have another possible implementation approach: to do it directly in the kernel when booting from vmlinux, see this patchset, then it doesn't need any changes in VMM, however, I'm not sure if it would be acceptable by the x86 folks.

Additional context

Checks

• [*] Have you searched the Firecracker Issues database for similar requests?
• [*] Have you read all the existing relevant Firecracker documentation?
• [*] Have you read and understood Firecracker's core tenets?

[zulinx86]

Hi @bysui ,
Thanks for creating this feature request!

Discussing internally, we came to the following:

• We don't plan to actively work on supporting it, because in realistic use cases microVMs are restored from snapshots, and in that scenario KASLR don't provide any real benefit.
• We'd absolutely welcome contributions from you!
• As an implementation approach, it would be great to add the support on the linux-loader side, and then introduce an opt-in feature in Firecracker that just uses the linux-loader support and keep the changes minimal.

I took a quick look at the issues on the linux-loader side and found a related issue regarding virtual KASLR (rust-vmm/linux-loader#138).

Thanks!

[bysui]

Hi, @zulinx86. Thanks for your kind reply.

Hi @bysui , Thanks for creating this feature request!

Discussing internally, we came to the following:

• We don't plan to actively work on supporting it, because in realistic use cases microVMs are restored from snapshots, and in that scenario KASLR don't provide any real benefit.

Yes, KASLR is useless when restoring from a snapshot.

• We'd absolutely welcome contributions from you!
• As an implementation approach, it would be great to add the support on the linux-loader side, and then introduce an opt-in feature in Firecracker that just uses the linux-loader support and keep the changes minimal.

Yes, we're considering implementing it for cloud-hypervisor as well, so adding support on the linux-loader side seems to be the right approach.

I took a quick look at the issues on the linux-loader side and found a related issue regarding virtual KASLR (rust-vmm/linux-loader#138).

I also saw the issue before creating this one; however, I see no replies on that issue, so I chose to open this issue to add a feature request for a VMM. Then, I can respond there for further discussion.

Thanks!

[zulinx86]

Hello @bysui !

Sounds like a plan! Feel free to reach us if you need our help!