linux-kernel - Re: [PATCH] driver/virtio: Add Memory Balloon Support for SEV/SEV-ES

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dfb2662d-900e-4b36-b2a0-78ad7f397861@redhat.com>
Date: Thu, 11 Jan 2024 09:22:56 +0100
From: David Hildenbrand <david@...hat.com>
To: Zheyun Shen <szy0127@...u.edu.cn>, Jason Wang <jasowang@...hat.com>,
 mst <mst@...hat.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
 virtualization <virtualization@...ts.linux.dev>,
 xuanzhuo <xuanzhuo@...ux.alibaba.com>
Subject: Re: [PATCH] driver/virtio: Add Memory Balloon Support for SEV/SEV-ES

>>> For now, SEV pins guest's memory to avoid swapping or
>>> moving ciphertext, but leading to the inhibition of
>>> Memory Ballooning.
>>>
>>> In Memory Ballooning, only guest's free pages will be relocated
>>> in balloon inflation and deflation, so the difference of plaintext
>>> doesn't matter to guest.
> 
>> This seems only true if the page is zeroed, is this true here?
> 
> Sorry, I cannot figure out why the pages should be zeroed. I think
> both host kernel and guest kernel assume that the pages are not
> zeroed and will use kzalloc or manually zero them in real applications,
> which is same as non-SEV environments.

balloon_page_alloc() will not zero the memory (no __GFP_ZERO set). Only 
in some configurations (zero-on-alloc, zero-on-free), the kernel would 
do that implicitly.

So we'd eventually be leaking secrets to the untrusted hypervisor?


> I have tested in SEV-ES, reclaiming memory by balloon inflation and reuse
> them after balloon deflation both works well with the patch. Hypervisor
> can normally give the reclaimed memory from one CVM to another, or give
> back to the origin CVM.

I'll comment on your misconception of memory overcommit separately.

-- 
Cheers,

David / dhildenb