[Feature Request] ELF loader support for physical/virtual KASLR · Issue #5661 · firecracker-microvm/firecracker · GitHub
Skip to content

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

Open
Open
[Feature Request] ELF loader support for physical/virtual KASLR#5661
Labels
Priority: LowIndicates that an issue or pull request should be resolved behind issues or pull requests labelled `Status: ParkedIndicates that an issues or pull request will be revisited later

Description

@bysui
bysui
opened on Jan 30, 2026

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?

Activity

  1. zulinx86 commented on Feb 10, 2026

    @zulinx86
    zulinx86
    on Feb 10, 2026
    Contributor

    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/rust-vmm#84).

    Thanks!

  2. Manciukic
    added
    Status: Awaiting authorIndicates that an issue or pull request requires author action
    on Feb 11, 2026

  3. bysui commented on Feb 13, 2026

    @bysui
    bysui
    on Feb 13, 2026
    Author

    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/rust-vmm#84).

    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!

  4. zulinx86 commented on Feb 13, 2026

    @zulinx86
    zulinx86
    on Feb 13, 2026
    Contributor

    Hello @bysui !

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

  5. Manciukic
    added
    Priority: LowIndicates that an issue or pull request should be resolved behind issues or pull requests labelled `
    Status: ParkedIndicates that an issues or pull request will be revisited later
    and removed
    Status: Awaiting authorIndicates that an issue or pull request requires author action
    on Mar 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Priority: LowIndicates that an issue or pull request should be resolved behind issues or pull requests labelled `Status: ParkedIndicates that an issues or pull request will be revisited later

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions