I assume they chose it as their target because Firecracker, like most Linux KVM userspace [0], maps guest memory into its own address space, giving an easy place to write gadgets.
My personal favorite thing to poke into pt_regs is an actual privileged (CPL0) context. [1] Returning from the kernel right back to a controlled kernel context is allowed by the CPU :)
[0] Until fairly recently this was mandatory. These days it’s possible to ask KVM to map something into the guest without having it in host userspace memory.
[1] Corrupt pt_regs so it executes user memory in kernel mode:
https://seclists.org/oss-sec/2015/q3/291
I think this may be my favorite of all exploits I’ve ever written. In fact, I often made a point of not writing interesting exploits for corruption bugs I found, but this one was too much fun to pass up.
Which like, isn't really a proof of concept of anything being described.
"That was always allowed".
It just bothers me that the proof of concept starts with the assumption that host physical memory is mapped into guest physical memory at 2^39. If you can't talk about the actual exploit yet, I get it , but don't write a blog post with something like that called a "proof of concept" when the code shows no exploit, and you're obviously dancing around the actual novel exploit here in the chain. Just keep it in your pants until the disclosure window.