Re: [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 24/03/2023 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).

This pKVM implementation would definitely be useful to protect the host from itself (i.e. improved kernel self-protection) thanks to the Hypervisor-Enforced Kernel Integrity patch series: https://lore.kernel.org/all/20230505152046.6575-1-mic@xxxxxxxxxxx/

Use cases would then include all bare metal Linux systems with security requirements. They would initially configure pKVM with the dedicated Heki hypercalls, but not necessarily launch guest VMs.



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





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux