You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when using anonymous memory for KVM guest RAM, the memory all remains mapped into the kernel direct map. We are looking at options to get KVM guest memory out of the kernel’s direct map as a principled approach to mitigating speculative execution issues in the host kernel. Our goal is to more completely address the class of issues whose leak origin is categorized as "Mapped memory" [1].
As part oft his initiative, we plan to work with the upstream Linux kernel community [2] to design a solution that allows us to remove a microVMs guest memory from the host kernel's address space, which we will then consume in Firecracker.
The text was updated successfully, but these errors were encountered:
Currently when using anonymous memory for KVM guest RAM, the memory all remains mapped into the kernel direct map. We are looking at options to get KVM guest memory out of the kernel’s direct map as a principled approach to mitigating speculative execution issues in the host kernel. Our goal is to more completely address the class of issues whose leak origin is categorized as "Mapped memory" [1].
As part oft his initiative, we plan to work with the upstream Linux kernel community [2] to design a solution that allows us to remove a microVMs guest memory from the host kernel's address space, which we will then consume in Firecracker.
The text was updated successfully, but these errors were encountered: