* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Fri, Dec 16, 2022 at 08:32:44AM -0500, Stefan Berger wrote: > > > > > > On 12/16/22 07:54, Daniel P. Berrangé wrote: > > > On Fri, Dec 16, 2022 at 07:28:59AM -0500, Stefan Berger wrote: > > > > > > > > > > > > On 12/16/22 05:27, Daniel P. Berrangé wrote: > > > > > On Thu, Dec 15, 2022 at 03:53:43PM -0500, Stefan Berger wrote: > > > > > > > > > > > > > > > > > > On 12/15/22 15:30, James Bottomley wrote: > > > > > > > On Thu, 2022-12-15 at 15:22 -0500, Stefan Berger wrote: > > > > > > > > On 12/15/22 15:07, James Bottomley wrote: > > > > > > > [...] > > > > > > > > > don't really have much interest in the migration use case, > > > > > > > > > but I > > > > > > > > > knew it should work like the passthrough case, so that's what > > > > > > > > > I > > > > > > > > > tested. > > > > > > > > > > > > > > > > I think your device needs to block migrations since it doesn't > > > > > > > > handle > > > > > > > > all migration scenarios correctly. > > > > > > > > > > > > > > Passthrough doesn't block migrations either, presumably because > > > > > > > it can > > > > > > > also be made to work if you know what you're doing. I might not > > > > > > > be > > > > > > > > > > > > Don't compare it to passthrough, compare it to swtpm. It should > > > > > > have at least the same features as swtpm or be better, otherwise > > > > > > I don't see why we need to have the backend device in the upstream > > > > > > repo. > > > > > > > > > > James has explained multiple times that mssim is a beneficial > > > > > thing to support, given that it is the reference implementation > > > > > of TPM2. Requiring the same or greater features than swtpm is > > > > > an unreasonable thing to demand. > > > > > > > > Nevertheless it needs documentation and has to handle migration > > > > scenarios either via a blocker or it has to handle them all > > > > correctly. Since it's supposed to be a TPM running remote you > > > > had asked for TLS support iirc. > > > > > > If the mssim implmentation doesn't provide TLS itself, then I don't > > > consider that a blocker on the QEMU side, merely a nice-to-have. > > > > > > With swtpm the control channel is being used to load and store state > > > during the migration dance. This makes the use of an external process > > > largely transparent to the user, since QEMU handles all the state > > > save/load as part of its migration data stream. > > > > > > With mssim there is state save/load co-ordination with QEMU. Instead > > > whomever/whatever is managing the mssim instance, is responsible for > > > ensuring it is running with the correct state at the time QEMU does > > > a vmstate load. If doing a live migration this co-ordination is trivial > > > if you just use the same mssim instance for both src/dst to connect to. > > > > > > If doing save/store to disk, the user needs to be able to save the mssim > > > state and load it again later. If doing snapshots and reverting to old > > > > There is no way for storing and loading the *volatile state* of the > > mssim device. > > > > > snapshots, then again whomever manages mssim needs to be keeping saved > > > TPM state corresponding to each QEMU snapshot saved, and picking the > > > right one when restoring to old snapshots. > > > > This doesn't work. > > Either way, if it's possible it can be documented and shown how this works. > > > > > > > > QEMU exposes enough functionality to enable a mgmt app / admin us> > > > achieve all of this. > > > > How do you store the volatile state of this device, like the current > > state of the PCRs, loaded sessions etc? It doesn't support this. > > > > > > > > This is not as seemlessly integrated with swtpm is, but it is still > > > technically posssible todo the right thing with migration from QEMU's > > > POV. Whether or not the app/person managing mssim instance actually > > > does the right thing in practice is not a concern of QEMU. I don't > > > see a need for a migration blocker here. > > > > I do see it because the *volatile state* cannot be extracted from > > this device. The state of the PCRs is going to be lost. > > All the objections you're raising are related to the current > specifics of the implementation of the mssim remote server. > While valid, this is of no concern to QEMU when deciding whether > to require a migration blocker on the client side. This is 3rd > party remote service that should be considered a black box from > QEMU's POV. It is possible to write a remote server that supports > the mssim network protocol, and has the ability to serialize > its state. Whether such an impl exists today or not is separate.
We would normally want an example of a working implementation though wouldn't we? So I think it's fair to at least want some documentation; if it can be documented and works, fine; if it doesn't work, then it needs a blocker. Dave > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
