RE: [RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv

2024-03-07 Thread Michael Kelley
From: Edgecombe, Rick P Sent: Thursday, March 7, 2024 11:12 AM > > On Thu, 2024-03-07 at 17:11 +, Michael Kelley wrote: > > Using your patches plus the changes in my comments, I've > > done most of the testing described above. The normal > > paths work, and when I hack

Re: [RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv

2024-03-07 Thread Edgecombe, Rick P
On Thu, 2024-03-07 at 17:11 +, Michael Kelley wrote: > Using your patches plus the changes in my comments, I've > done most of the testing described above. The normal > paths work, and when I hack set_memory_encrypted() > to fail, the error paths correctly did not free the memory. > I checked

RE: [RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv

2024-03-07 Thread Michael Kelley
From: Michael Kelley Sent: Friday, March 1, 2024 11:00 AM > > > > IMPORTANT NOTE: > > I don't have a setup to test tdx hyperv changes. These changes are compile > > tested only. Previously Michael Kelley suggested some folks at MS might be > > able to help with this. > > Thanks for doing these

RE: [RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv

2024-03-01 Thread Michael Kelley
From: Rick Edgecombe Sent: Wednesday, February 21, 2024 6:10 PM > > Shared (decrypted) pages should never return to the page allocator, or > future usage of the pages may allow for the contents to be exposed to the > host. They may also cause the guest to crash if the page is used in way >

[RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv

2024-02-21 Thread Rick Edgecombe
Shared (decrypted) pages should never return to the page allocator, or future usage of the pages may allow for the contents to be exposed to the host. They may also cause the guest to crash if the page is used in way disallowed by HW (i.e. for executable code or as a page table). Normally