[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH v4 06/20] core: add new security-policy obje

From: Brijesh Singh
Subject: Re: [Qemu-devel] [RFC PATCH v4 06/20] core: add new security-policy object
Date: Mon, 27 Mar 2017 11:11:10 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 03/27/2017 07:04 AM, Stefan Hajnoczi wrote:
On Fri, Mar 24, 2017 at 02:42:47PM -0500, Brijesh Singh wrote:

On 03/24/2017 10:40 AM, Stefan Hajnoczi wrote:

Having one security policy doesn't make sense to me.  As mentioned,
there are many different areas of QEMU that have security relevant
configuration.  They are all unrelated so combining them into one object
with vague parameter names like "debug" makes for a confusing
command-line interface.

If the object is called sev-security-policy then I'm happy.

Works for with me but one of the feedback was to use security-policy [1].
IIRC, the main reason for using 'security-policy' instead of 
was to add a layer of abstraction so that in future if other platforms supports
memory encryption in slightly different way then all we need to do is to create
new object without needing to add a new parameter in -machine.

[1] http://marc.info/?l=qemu-devel&m=147388592213137&w=2

How about using 'memory-encryption-id' instead of security-policy ? If user 
to launch SEV guest then memory-encryption-id should be set SEV specific object.
Something like this:

-machine ..,memory-encryption-id=sev0 \
-object sev-guest,id=sev,debug=off,launch=launch0 \
-object sev-launch-info,id=launch0 \

Something like that sounds good.  I think "-id" typically isn't included
in the option name.

So just the following is fine:

 -machine memory-encryption=sev0 \

Other examples: -device virtio-blk-pci,drive=drive0 and -device

Sounds good. I will take care of this in next rev. thanks for review


reply via email to

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