On 6/9/23 20:44, Dmytro Maluka wrote: > On 6/9/23 18:57, Trilok Soni wrote: >> On 6/8/2023 2:06 PM, 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). >> >> >> Very interesting usecases. I would be interested to know how you plan to >> paravirt the clocks and regulators required for these devices on the guest VM (Protected VM) on x86. On ARM, we have SCMI specification w/ >> virtio-scmi, it is possible to do the clock and regulators paravirt. > > On x86 things like clocks and regulators tend to be abstracted away via > ACPI, i.e. they are managed by AML code in ACPI tables, not by the > device driver in kernel. With pKVM, ACPI is still fully managed by the > host, although the secure device driver is running in the protected VM. > > So at least in theory this is automatically solved for us in most cases > (though admittedly it is only a theory so far, we have no > proof-of-concept yet, see below). > >> Camera may have need more h/w dependencies than clocks and regulators like flash LEDs, gpios, IOMMUs, I2C on top of the camera driver pipeline itself. > > When it comes to camera, we are rather considering not a separate > physical camera but a secure image stream, separated from non-secure > image stream from the same camera e.g. with Intel IPU6. In this case > the assigned device (the IPU) is within the SoC. There are actually lots > of challenges with its assignment too, but completely different ones > (how to partition it between the host and the VM and ensure protection > from the host). On second thought, the "within the SoC" point is probably not important. What's important is that the protected guest needs only a small part of the IPU hw functionality - the one related to the secure camera data channel. Among the things you mentioned, the IPU's internal IOMMU needs to be assigned to the guest, as it's crucial that the secure VM has exclusive control over this IOMMU to ensure DMA isolation between secure and non-secure data channels. (The host IOMMU, managed by pKVM hypervisor, needs to be involved too but is not enough.) Others things (GPIOs, clocks etc) are left to the host IPU driver and/or ACPI. How shall we assign the IPU IOMMU to the guest? In the IPU's device specific ways, unfortunately. Hopefully for other use cases we can do things more generically, as we can pass-through the entire device to the guest, except for the power management bits which are already effectively partitioned away via ACPI. >> Do you have any proof-of-concept for above usecases to check and reproduce on the chrome w/ x86? > > Not really yet. We've been focused on evaluating functionality and > performace of ChromeOS itself, i.e. whether ChromeOS works with pKVM as > good as natively, - without the actual protected VMs yet, but already > with pKVM functionality required for protected VMs (memory protection > etc). We've also been looking a lot into the issues of assignment and > protection of secure devices for protected VMs, but (apart from the > simple case of generic PCI devices) mostly theoretically so far. > >> Do we have the recording of the PUCK meeting? >> >> ---Trilok Soni
