encrypted snapshots

[Mikko Koivisto]

Are there any plans for encrypted snapshots in crosvm?  Our use case would include

- running Cuttlefish on cloud VM (using nested virtualisation)

- taking snapshot to network drive

- restoring from the snapshot on other cloud VM instance

regards,

Mikko

[Steven Moreland]

The real limitation for this right now is that snapshots aren't proven out to be portable between different machines/cpus.

As for encrypting a snapshot, if you have a system which manages snapshots for use between different machines, that system should be responsible for encrypting snapshots, metadata, or any other information which it manages. I'm not sure why encrypting snapshots should be something done in crosvm.

--
You received this message because you are subscribed to the Google Groups "crosvm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crosvm-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/1916ef36-9f4a-44b9-bcd5-e6a710cb7ae6n%40chromium.org.

[Noah Gold]

+1 to Steven's points. Snapshot portability is NOT currently supported and needs significant work.

CrosVM does have stubs in vendor/generic/crypto to support snapshot encryption. If an implementation of those stubs is vendored in, then the --encrypt=true flag will work on snapshot commands.

- Noah

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/CAKLm694V4e6iDQUK6EbZTfw%3DDWXry9tn7ijMHOYx41tCzxLj6Q%40mail.gmail.com.

[Frederick Mayle]

Also note that a Cuttlefish snapshot includes more than just the crosvm snapshot and none of it is encrypted

[Mikko Koivisto]

Thanks for the info and good points.

I'll check the vendor/generic/crypto. For the rest of the data I think we could first snapshot to some temporary location and encrypt the data there.

Do you have any more details about what is considered "different" when you mentioned that "snapshots aren't proven out to be portable between different machines/cpus."

regards,

Mikko

[Steven Moreland]

It's only tested today on the exact same physical machine. One thing that's likely to break is that different CPUs have different CPU errata, which the Linux kernel self-patches early during boot (https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/cpu_errata.c). So, to truly be portable and correct, we'll have to make sure crosvm tells the guest to patch all the errata for the different CPUs it may run on. Though, there may be other unknown issues as portability hasn't been tested. If you do try it and find anything interesting, please let us know, as we are beginning to look into these things. Thank you!

[Daniel Verkamp]

In addition to what Steven mentioned, in general, crosvm mostly just
passes through the host CPU's features (CPUID bits), so migrating
between hosts with different CPU models (for example, one with AVX2
support to one without) will definitely not work correctly today.

-- Daniel