On 06/06/2018 09:08 PM, bushuanshuan wrote:

...

...

+static int

...

+qemuExtTPMStartEmulator(virQEMUDriverPtr driver,

...

+                        virDomainDefPtr def,

...

+                        qemuDomainLogContextPtr logCtxt)

...

+{

...

...

+    if (!(cmd = qemuTPMEmulatorBuildCommand(tpm, def->name, def->uuid,

...

+ driver->privileged,

...

+    cfg->swtpm_user,

...

+ cfg->swtpm_group)))

...

+        goto cleanup;

...

+

...

+    if (qemuExtDeviceLogCommand(logCtxt, cmd, "TPM Emulator") < 0)

...

+        goto cleanup;

...

+

...

+ virCommandSetErrorBuffer(cmd, &errbuf);

...

+

...

+    if (virCommandRun(cmd, &exitstatus) < 0 || exitstatus != 0) {

...

+ virReportError(VIR_ERR_INTERNAL_ERROR,

...

+                       _("Could not start 'swtpm'. exitstatus: %d, "

...

+                         "error: %s"), exitstatus, errbuf);

...

+        goto cleanup;

...

+    }

Now that the sensitive data in NVRAM need to be protected,  it might be a feasible way that swtpm uses the 'key' to encrypt it when VM shutdown.

I wonder why don't use the key when swtpm process is launched here.

Adding support for vTPM state encryption can be added later on, but then only be used for newly created vTPMs (those that are not encyrpted remain not encrypted).

Of course, we should avoid to let the key exposed in system log when we design the encryption scheme.

Another question is: where we can store the key securely. Maybe physical TPM can help this.

What do you think about this question?

libvirt supports 'secrets' and they could be encrypted by a TPM. So far I think they are primarily protected through file access control bits.     Stefan

...

Thanks,

Shuanshuan Bu