Re: [Qemu-devel] fw cfg files cross-version migration races

[Gabriel L. Somlo]

On Tue, Jun 02, 2015 at 09:11:14AM +0200, Gerd Hoffmann wrote:
> > I guess the only reason this isn't a problem is that nobody currently
> > attempts to access fw_cfg after a migration ? :)
> 
> Accessing fw_cfg after migration is fine.  Problem is this ...
> 
>   (1) read directory
>   (2) migrate
>   (3) read file
> 
> ... in case the file ordering happens to be different on the destination
> host due to initialization order changes.

I get this part :) Right now, most of the fw_cfg files get added
before command line options are processed, but some (like etc/tpm/log)
get added after. When all is said and done, *at least* the
user-provided blobs may be ordered differently when a saved guest
state is loaded.
 
> So, sorting entries (and the index assigned too) should fix this, right?
> That looks easiest to me.

Presumably, anything happening before (and after) user-provided blobs
are inserted will continue happening in the same order everywhere.
So we really only have to sort the user provided blobs, so that if
the same *set* is provided on both ends of the migration, things would
work out OK.

If a *different* set of blobs is specified on the migration origin vs.
the migration destination, we lose by default and worrying about it is
pointless -- did I get that right ? If yes, figuring out there's a
mismatch and declaring the migration failed would be a nice extra
feature, wonder if that's possible...

Thanks,
--Gabriel

PS.
At some point earlier in the thread I *thought* adding the actual blob
data to the state being migrated would help, but (and I would like to
have that assertion sanity checked, please) that would be crazy, since
a lot (most?) of the FwCfgEntry 'data' pointers are actually locations
within the qemu process on the host machine, and therefore subject to
the local host memory allocator, and wouldn't "translate" between the
migration source and destination.

Having both the source and destination dereference their own local
pointers based on 'cur_entry' and 'cur_offset' (the only state being
migrated, and rightfully so) works only if 'entries' and 'files'
have the same order.