Hello Boris, On 11/15/2022 10:27 AM, Borislav Petkov wrote:
And, as dhansen connected the dots, this should be the exact same protection scenario as UPM: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20221025151344.3784230-1-chao.p.peng%40linux.intel.com&data=05%7C01%7Cashish.kalra%40amd.com%7Cbfecf32a51eb499b526d08dac726491e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638041264625164355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3RqOC3b9qn0%2B2IRsTZURBmhAVtOn7rARR6fOMOsrFpE%3D&reserved=0 so you should be able to mark them inaccessible the same way and you won't need any poisoning dance.
With UPM, the guest pages are all still freed back to the host after guest shutdown, so it's not clear how this would help with handling of leaked pages, for e.g, the host can still access these pages once the guest is shutdown and it will cause the RMP violation #PF at that point.
Additionally, our use case is of host allocated firmware pages as part of the crypto driver (to be passed to SNP firmware api calls and then re-transitioned back to host state on return) so these are not guest private pages in the true sense and they need to be
handled differently in case there is a failure in reclaiming them. Can you elaborate on what you have in mind ? Thanks, Ashish
And Michael has patches so you probably should talk to him... Thx.
