Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled
From: Kalra, Ashish
Date: Tue Nov 15 2022 - 17:45:04 EST
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.