[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: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 06/20] core: add new security-policy object |
Date: |
Mon, 27 Mar 2017 13:04:04 +0100 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
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
> 'sev-security-policy'
> 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
> wants
> 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
e1000,netdev=netdev0.
Stefan
signature.asc
Description: PGP signature
- [Qemu-devel] [RFC PATCH v4 04/20] exec: add debug version of physical memory read and write api, (continued)
- [Qemu-devel] [RFC PATCH v4 04/20] exec: add debug version of physical memory read and write api, Brijesh Singh, 2017/03/08
- [Qemu-devel] [RFC PATCH v4 05/20] monitor/i386: use debug apis when accessing guest memory, Brijesh Singh, 2017/03/08
- [Qemu-devel] [RFC PATCH v4 01/20] kvm: update kvm.h header file, Brijesh Singh, 2017/03/08
- [Qemu-devel] [RFC PATCH v4 08/20] sev: add Secure Encrypted Virtulization (SEV) support, Brijesh Singh, 2017/03/08
- [Qemu-devel] [RFC PATCH v4 13/20] sev: add LAUNCH_UPDATE_DATA command, Brijesh Singh, 2017/03/08
- [Qemu-devel] [RFC PATCH v4 06/20] core: add new security-policy object, Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 11/20] sev: add LAUNCH_START command, Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 03/20] exec: add guest RAM read and write ops, Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 10/20] vl: add memory encryption support, Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 09/20] hmp: display memory encryption support in 'info kvm', Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 12/20] SEV: add GUEST_STATUS command, Brijesh Singh, 2017/03/08
[Qemu-devel] [RFC PATCH v4 14/20] sev: add LAUNCH_FINISH command, Brijesh Singh, 2017/03/08