Re: [PATCH v9 06/17] qemu: Extend QEMU with external TPM support

Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx> · Thu, 7 Jun 2018 07:10:12 -0400



    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
         
      
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list