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

[Stefan Hajnoczi]

On Thu, Mar 23, 2017 at 01:59:48PM -0500, Brijesh Singh wrote:
> Hi Stefan,
> 
> 
> On 03/23/2017 06:35 AM, Stefan Hajnoczi wrote:
> > On Wed, Mar 08, 2017 at 03:52:09PM -0500, Brijesh Singh wrote:
> > > The object can be used to define global security policy for the guest.
> > 
> > "security-policy" is very vague.  Lots of parts of QEMU have security
> > related options (e.g. VNC display, networking, etc).
> > 
> > I'd prefer a
> > -machine memory-encryption=on|off,memory-encryption-debug=on|off
> > or -m encryption=on|off,encryption-debug=on|off switch instead of a new
> > security policy object with questionable scope.
> > 
> 
> In v1 [1], I had something similar but not exactly the same. I had a new 
> command
> line switch but the overall feedback was to consider creating new security 
> object
> which can be used to define a machine security policy.
> 
> [1] http://marc.info/?t=147378617700002&r=1&w=2
> 
> some more discussion here [2]
> 
> [2] http://marc.info/?t=147378241700011&r=1&w=2
> 
> IMHO, a new object is helpful because it provide options to launch a guest 
> without
> memory encryption support but still can take a advantage of disabling the 
> debug
> feature. e.g on non SEV platform we can launch guest with "-object 
> security-policy,id=secure0,debug=off'
> which will reject the guest memory accesses via gdbstub or qemu monitor 
> command line interface.

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.

Stefan

signature.asc
Description: PGP signature