On 30/11/2023 10:21, Borislav Petkov wrote: > On Thu, Nov 30, 2023 at 08:31:03AM +0000, Reshetova, Elena wrote: >> No threats whatsoever, > > I don't mean you - others. :-) > >> I just truly don’t know details of SEV architecture on this and how it >> envisioned to operate under this nesting scenario. I raised this >> point to see if we can build the common understanding on this. My >> personal understanding (please correct me) was that SEV would also >> allow different types of L2 guests, so I think we should be aligning >> on this. > > Yes, makes sense. The only L2 thing I've heard of is some Azure setup. "L2" is the Intel terminology in TD-partitioning (see figure 11.2 in [1]), but Azure uses it for the exact same thing as VMPLs in SEV-SNP. On the AMD side the community is working on Coconut SVSM[2] and there was an AMD SVSM[3] project before that, both of them have the same idea as the Azure paravisor. SUSE, Red Hat, IBM and others are active in SVSM development, we've also started contributing. I think this kind of usage will also appear on TDX soon. [1]: https://cdrdv2.intel.com/v1/dl/getContent/773039 [2]: https://github.com/coconut-svsm/svsm [3]: https://github.com/AMDESE/linux-svsm > >> Yes, agree, so what are our options and overall strategy on this? We >> can try to push as much as possible complexity into L1 VMM in this >> scenario to keep the guest kernel almost free from these sprinkling >> differences. > > I like that angle. :) > >> Afterall the L1 VMM can emulate whatever it wants for the guest. >> We can also see if there is a true need to add another virtualization >> abstraction here, i.e. "nested encrypted guest". > > Yes, that too. I'm sceptical but there are use cases with that paravisor > thing and being able to run an unmodified guest, i.e., something like > a very old OS which no one develops anymore but customers simply can't > part ways with it for raisins I don't think we'll be seeing Windows XP TDX/SNP guests :) The primary use case for the paravisor (/SVSM) is pretty common across the the industry and projects that I shared: TPM emulation. Then comes the other stuff: live migration, "trustlets", further device emulation. All this inside the confidential boundary. > >> Any other options we should be considering as overall strategy? > > The less the kernel knows about guests, the better, I'd say. > The challenge lies in navigating the Venn diagram of: standard guest, TDX guest and SNP guest. Is a "guest" more "TDX" or more "Hyper-V" (or KVM/Vmware)? Should the TDX (and SNP) code be extended with more knowledge of hypervisor interfaces or should the hypervisor interfaces know more about TDX/SNP. I'd love it if we all had some agreement on this. I posted these patches based on suggestions that TDX guest-ness takes precedence. > The other thing I'm missing most of the time is, people come with those > patches enabling this and that but nowhere does it say: "we would love > to have this because of this great idea we had" or "brings so much more > performance" or "amazing code quality imrpovement" or, or other great > reason. > > Rather, it is "yeah, we do this and you should support it". Well, nope. > I hear you, that's we've been making an effort to be more open about use cases and capabilities along with patches. We also care about simplifying the code to make it easier to follow the flows. I think the whole kernel has come a long way since the first confidential guest patches were posted. Jeremi > Thx. >
