On 3/24/23 11:30, Keir Fraser wrote: > On Tue, Mar 14, 2023 at 07:21:18AM -0700, Sean Christopherson wrote: >> On Tue, Mar 14, 2023, Jason Chen CJ wrote: >>> On Mon, Mar 13, 2023 at 09:33:41AM -0700, Sean Christopherson wrote: >>> >>>> On Mon, Mar 13, 2023, Jason Chen CJ wrote: >>>>> There are similar use cases on x86 platforms requesting protected >>>>> environment which is isolated from host OS for confidential computing. >>>> >>>> What exactly are those use cases? The more details you can provide, the better. >>>> E.g. restricting the isolated VMs to 64-bit mode a la TDX would likely simplify >>>> the pKVM implementation. >>> >>> Thanks Sean for your comments, I am very appreciated! >>> >>> We are expected >> >> Who is "we"? Unless Intel is making a rather large pivot, I doubt Intel is the >> end customer of pKVM-on-x86. If you aren't at liberty to say due NDA/confidentiality, >> then please work with whoever you need to in order to get permission to fully >> disclose the use case. Because realistically, without knowing exactly what is >> in scope and why, this is going nowhere. > > This is being seriously evaluated by ChromeOS as an alternative to > their existing ManaTEE design. Compared with that (hypervisor == full > Linux) the pKVM design is pretty attractive: smaller TCB, host Linux > "VM" runs closer to native and without nested scheduling, demonstrated > better performance, and closer alignment with Android virtualisation > (that's my team, which of course is ARM focused, but we'd love to see > broader uptake of pKVM in the kernel). Right, we (Google with the help of Semihalf and Intel) have been evaluating pKVM for ChromeOS on Intel platforms (using this Intel's pKVM-on-x86 PoC) as a platform for running secure workloads in VMs protected from the untrusted ChromeOS host, and it looks quite promising so far, in terms of both performance and design simplicity. The primary use cases for those secure workloads on Chromebooks are for protection of sensitive biometric data (e.g. fingerprints, face authentication), which means that we expect pKVM to provide not just the basic memory protection for secure VMs but also protection of secure devices assigned to those VMs (e.g. fingerprint sensor, secure camera). Summarizing what we discussed at PUCK [1] regarding the existing pKVM design (with kernel deprivileging) vs pKVM using SEAM (please correct me if I'm missing something): - As we are interested in pKVM for client-side platforms (Chromebooks) which have no SEAM hardware, using SEAM does not seem to be an option at all. And even if it was, we still prefer the current (software based) pKVM design, since we need not just memory protection but also device protection, and generally we prefer to have more flexibility. - Sean had a concern that kernel deprivileging may require intrusive changes in the common x86 arch code outside KVM, but IIUC it's not quite the case. AFAICT the code needed for deprivileging (i.e. making the kernel run in VMX non-root as a VM) is almost fully contained within KVM, i.e. the rest of the kernel can remain largely agnostic of the fact that it is running in VMX non-root. (Jason, please correct me if I'm wrong.) Outside KVM, there is a bit of changes in drivers/intel/iommu/ for a bit of PV stuff for IOMMU in pKVM (not sure if that is already included in this RFC), and if we go with a more PV based design [2] and not just for VMX and EPT but also for IOMMU, then I expect we're gonna have more of such PV changes for pKVM there, but still contained within Intel IOMMU driver. [1] https://lore.kernel.org/kvm/20230606181525.1295020-1-seanjc@xxxxxxxxxx/ [2] https://lore.kernel.org/all/ZA9WM3xA6Qu5Q43K@xxxxxxxxxx/ Thanks, Dmytro > > -- Keir > >>> to run protected VM with general OS and may with pass-thru secure devices support. >> >> Why? What is the actual use case? >> >>> May I know your suggestion of "utilize SEAM" is to follow TDX SPEC then >>> work out a SW-TDX solution, or just do some leverage from SEAM code? >> >> Throw away TDX and let KVM run its own code in SEAM. >>
