On 12/14/2022 2:08 AM, Michael Kelley (LINUX) wrote:
From: Tianyu Lan <ltykernel@xxxxxxxxx> Sent: Friday, November 18, 2022 7:46 PM
The Subject prefix for this patch should be "Drivers: hv: vmbus:"
Sure. Will update in the next version.
Vmbus int, synic and post message pages are shared with hypervisor
and so decrypt these pages in the sev-snp guest.
Signed-off-by: Tianyu Lan <tiala@xxxxxxxxxxxxx>
---
drivers/hv/connection.c | 13 +++++++++++++
drivers/hv/hv.c | 32 +++++++++++++++++++++++++++++++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 9dc27e5d367a..43141225ea15 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -215,6 +215,15 @@ int vmbus_connect(void)
(void *)((unsigned long)vmbus_connection.int_page +
(HV_HYP_PAGE_SIZE >> 1));
+ if (hv_isolation_type_snp() || hv_isolation_type_en_snp()) {
This decryption should be done only for a fully enlightened SEV-SNP
guest, not for a vTOM guest.
+ ret = set_memory_decrypted((unsigned long)
+ vmbus_connection.int_page, 1);
+ if (ret)
+ goto cleanup;
This cleanup path doesn't work correctly. It calls
vmbus_disconnect(), which will try to re-encrypt the memory.
But if the original decryption failed, re-encrypting is the wrong
thing to do.
It looks like this same bug exists in current code if the decryption
of the monitor pages fails or if just one of the original memory
allocations fails. vmbus_disconnect() doesn't know whether it
should re-encrypt the pages.
Agree. It's necessary to handle decryption failure case by case in stead
of re-encryting all pages. Will fix this in the next version. Thanks to
point out.
