On 5/13/2025 9:00 PM, Michael Kelley wrote:
From: Roman Kisel <rom...@linux.microsoft.com> Sent: Friday, May 9, 2025 11:05
AM
On 5/9/2025 11:02 AM, Saurabh Singh Sengar wrote:
[...]
Yep. We don't rely on user land software doing sane things to maintain
correctness in kernel, so this needs to be fixed.
Thanks,
Wei.
How about fixing this for normal x86 for now and put a TODO for CVM to be fixed
later, when we bring in CVM support ?
That seems to strike the right balance ihmo :)
Thanks for coming up with the suggestion!
FWIW, it seems like it would be pretty easy to fix the CVM case as well. Do
the following:
1. Allocate memory at runtime using the normal kmalloc()
2. Copy from user space to that allocated memory
3. Disable interrupts as usual for using the per-cpu hypercall arg pages
4. Copy from the allocated memory to the per-cpu hypercall arg pages.
In a CVM this will do the conversion from encrypted memory to
decrypted memory.
5. Make the hypercall
6. Copy out any results to the allocated memory. Again, this will do
the conversion from decrypted to encrypted.
7. Enable interrupts
8. Copy results from the allocated memory to user space
9. Free the allocated memory
(And maybe Steps 6 and 8 don't apply if there's no output data to copy
back to user space.)
The performance penalty is the memory allocation/free, plus the extra
copying of the input/output hypercall arguments. But I'm guessing the
arguments are usually on the small side, so the extra copy isn't a big issue.
Michael
Thanks for looking into this Michael. The steps you have highlighted
makes sense. There is an implementation for this here:
https://github.com/microsoft/OHCL-Linux-Kernel/blob/product/hcl-main/6.12/drivers/hv/mshv_vtl_main.c#L2275
Since CVM use-case does not exist as of today in my patch, we thought of
adding this in future patches when we add CVM support.
Regards,
Naman
