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.
