On 6/9/23 01:02, tina.zhang wrote: > > > On 6/9/23 05:06, Dmytro Maluka wrote: >> 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. > Thanks Dmytro for the summarizing. I just want to add a bit update about > the PV stuff for Intel IOMMU driver: we took deep look into the > solution[1] proposed by pKVM-ARM folks and we think it's promising > especially for the platforms that have no hardware IOMMU nested > translation support. If PV is going to be the direction, we'd like to > try the solution on pKVM-IA. Hi Tina, Thanks for the info, looks quite interesting. Yeah, I agree that PV seems to be the best way to go. Also, using (fully or partially) the same PV interface as on ARM is probably a good idea too. > > [1]: > https://lore.kernel.org/linux-arm-kernel/20230201125328.2186498-14-jean-philippe@xxxxxxxxxx/T/ > > Regards, > -Tina >> >> [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. >>>>
