Comment 13 for bug 1456228

It is unclear if this is OSSN worthy, as it may be expected (if sub-optimal) behaviour. To recap, the steps listed to reproduce described above:

* 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.

I am under the impression that the trust status is only checked at boot time, so unless the node is rebooted after changing the boot order, the attestation information available to trusted_filter will still say that the node is trusted, and therefore will allow the instance to start. However, if the node is rebooted, the attestation information should prevent that node from restarting - this should be verified, although Slynvain states on 2015-06-24 that instances are spawned correctly, which implies that nova is functioning as it should.

Clearly this is sub-optimal to boot instances on a compromised nova node, but I believe this is expected behaviour for a trusted boot system (it is one of the known defects with trusted computing) . If I am correct, we should document this via the compute section of the security guide, rather than issuing an OSSN. Any update to the security guide should include the expected situations that the attestation service should prevent instance boot, and the cases where instances can still boot.