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). > 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
