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
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
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"
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-polic
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 disp
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-encryptio
The object can be used to define global security policy for the guest.
object provides two properties:
1) debug: can be used to disable guest memory access from hypervisor.
e.g to disable guest memory debug accesses
# $QEMU \
-object security-policy,debug=false,id=mypolicy \
