Comment 9 for bug 1456228

Wow, seriously? Sounds like joke...
 On Jun 23, 2015 3:56 AM, "Sylvain Bauza" <email address hidden> wrote:

> The TrustedFilter filter actually doesn't check by itself but rather
> calls the Attestation API to know if the destination host is correct or
> not. That way, it's just when the instance is scheduled that it goes to
> the scheduler, then finds an acceptable destination (so calls the
> Attestation API for each host to see if it's compromised or not) and
> then calls the corresponding compute node to spawn that VM.
>
> Once the VM is spawned, the scheduler is no longer involved unless a
> migration, a resize or an evacuation is asked for that VM.
> That means that having a valid host, running a VM, stopping it,
> compromising the host, then restarting the VM is something that Nova
> doesn't check, because it's not its responsibility.
>
> To be clear, Nova doesn't want to support that feature.
>
> ** Changed in: nova
> Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1456228
>
> Title:
> Trusted vm can be powered on untrusted host
>
> Status in OpenStack Compute (Nova):
> Invalid
> Status in OpenStack Security Advisories:
> Incomplete
>
> Bug description:
> This is related to the trusted compute.
>
> I recently setup trusted compute pool in my company and have observed
> that although new trusted vm is not able to be launched from an
> untrusted host, but if an trusted vm that have launched earlier on a
> trusted host which is compromised later on, that VM can still be
> powered on.
>
> 1. Exact version of Nova/Openstack:
> [root@grunt2 ~]# rpm -qa | grep nova
> python-nova-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch
> python-novaclient-2.17.0-2.fc21.noarch
> openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch
> openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch
>
> 2. Relevant log files:
> this is not a error, don't think logs will help..
>
> 3. Reproduce steps:
>
> * create trusted compute pool with only one compute node
> * create an trusted VM on that compute node
> * compromise the trusted compute node by changing the boot order
> * power on the trusted Vm created earlier.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1456228/+subscriptions
>