[Top][All Lists]

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

Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option

From: Janosch Frank
Subject: Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
Date: Mon, 3 Aug 2020 10:07:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 8/3/20 9:54 AM, David Gibson wrote:
> On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
>> On 7/24/20 4:57 AM, David Gibson wrote:
>>> At least some s390 cpu models support "Protected Virtualization" (PV),
>>> a mechanism to protect guests from eavesdropping by a compromised
>>> hypervisor.
>>> This is similar in function to other mechanisms like AMD's SEV and
>>> POWER's PEF, which are controlled bythe "host-trust-limitation"
>>> machine option.  s390 is a slightly special case, because we already
>>> supported PV, simply by using a CPU model with the required feature
>>> (S390_FEAT_UNPACK).
>>> To integrate this with the option used by other platforms, we
>>> implement the following compromise:
>>>  - When the host-trust-limitation option is set, s390 will recognize
>>>    it, verify that the CPU can support PV (failing if not) and set
>>>    virtio default options necessary for encrypted or protected guests,
>>>    as on other platforms.  i.e. if host-trust-limitation is set, we
>>>    will either create a guest capable of entering PV mode, or fail
>>>    outright
>>>  - If host-trust-limitation is not set, guest's might still be able to
>>>    enter PV mode, if the CPU has the right model.  This may be a
>>>    little surprising, but shouldn't actually be harmful.
>> As I already explained, they have to continue to work without any change
>> to the VM's configuration.
> Yes.. that's what I'm saying will happen.
>> Our users already expect PV to work without HTL. This feature is already
>> being used and the documentation has been online for a few months. I've
>> already heard enough complains because users found small errors in our
>> documentation. I'm not looking forward to complains because suddenly we
>> need to specify new command line arguments depending on the QEMU version.
>> @Cornelia: QEMU is not my expertise, am I missing something here?
> What I'm saying here is that you don't need a new option.  I'm only
> suggesting we make the new option the preferred way for future
> upstream releases.  (the new option has the advantage that you *just*
> need to specify it, and any necessary virtio or other options to be
> compatible should be handled for you).
> But existing configurations should work as is (I'm not sure they do
> with the current patch, because I'm not familiar with the s390 code
> and have no means to test PV, but that can be sorted out before
> merge).
OK, should and might are two different things so I was a bit concerned.
That's fine then, thanks for the answer.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]