On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote:It doesn't matter. This patch series, like XPFO, only removes guest memory pages from direct-map.
On 22/05/2020 15:51, Kirill A. Shutemov wrote:Objects allocated from slab use the direct map, vmalloc() is another story.
Furthermore, I would like to point out that just unmapping guest data from
kernel direct-map is not sufficient to prevent all
guest-to-guest info-leaks via a kernel memory info-leak vulnerability. This
is because host kernel VA space have other regions
which contains guest sensitive data. For example, KVM per-vCPU struct (which
holds vCPU state) is allocated on slab and therefore
Dig into XPFO mailing-list discussions to find out...
Out of curiosity, do we actually have some numbers for the "non-trivial- Touching direct mapping leads to fragmentation. We need to be able toAs I've mentioned above, not mapping all guest memory from 1GB hugetlbfs
recover from it. I have a buggy patch that aims at recovering 2M/1G page.
It has to be fixed and tested properly
will lead to holes in kernel direct-map which force it to not be mapped
anymore as a series of 1GB huge-pages.
This have non-trivial performance cost. Thus, I am not sure addressing this
use-case is valuable.
performance cost"? For instance for KVM usecase?