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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 7 Jun 2023 16:26:36 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Keir Fraser <keirf@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Jason Chen CJ <jason.cj.chen@...el.com>, kvm@...r.kernel.org,
        android-kvm@...gle.com, x86@...nel.org,
        linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction


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@digikod.net/

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