Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?

[Stefan Berger <stefanb@xxxxxxxxxx>]

jacobgorm@xxxxxxxxx wrote on 11/06/2006 03:27:17 AM:

> On 11/5/06, Stefan Berger <stefanb@xxxxxxxxxx> wrote:
> 
> > In terms of time needed for migration there won't be a difference.
Is
> > supporting that .suspend really so problematic?
> 
> I would love to see .suspend go away, when doing self-checkpointing
or
> self-migration it is very annoying to have to shut down external state
> at a point where things are supposed to be atomic in the middle of
> trying to take a checkpoint.
> 
> Can't you problem be solved simply by retrying the last TMP
> transaction if it fails, similar to how syscalls can fail in
> UNIX/Linux? Surely the backend has to be able to deal with these kinds
> of failure modes, or the guest would be able to DoS it pretty easily.

Once a TPM command has been started to be executed
it may change the internal state of the TPM, such as for example one of
its registers. If that command was to be executed a 2nd time it may again
change that register and lead to an unwanted state of the device. Registers
are not simply loaded on that device, but a hash operation is performed
on its contents that, if performed twice, leads to a totally different
result. Also the 'connection' to the device is assumed to be reliable -
it's usually an on-board chip.

Here's another email in regards to this:
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00234.html

Another problem occurrs when you migrate a domain
from one platform to another while not having the possibility of replaying
commands to a device. The device driver needs to be able to allow the migration-supporting
software to take a snapshot of the device's state after the n-th command
has finished and after only the n-th command has been sent by the domain.
At that point the OS's state and the device's state are completly in sync
and that's when you have to snapshot and not snapshot the domain after
issuing the n-th command and the device after the (n +/- x)th command.
This holds true for the TPM and is rather strict there, but maybe holds
also true for operations of a block device driver on a filesystem image.
A constructed scenarion for the block device would be to snapshot a filesystem
image and replicating it and only after that snapshot has been done the
OS on the source system issues a block operation to remove an inode. When
the OS appears on the target system it thinks it has removed the inode,
but in reality it's not reflected in that image. 

  Stefan

> 
> Jacob
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel