[libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

Pavel Hrdina phrdina at redhat.com
Fri Oct 14 15:30:12 UTC 2016


On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
> [...]
> >>
> >> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
> >> yet and that was the rest of this series...  Of course the rest of this
> >> series is adding the passphrase for the environment (<sigh>).
> >>
> >> If I could have got that review earlier, then this situation wouldn't be
> >> a problem (see in my mind it wasn't).
> >>
> >> If a domain is already running, then encryption is occurring and this
> >> setting has no effect except for hotplug.
> >>
> >> If we were using encryption in 2.3.0... stopped our domain... installed
> >> 2.4.0... started our domain, then yes, I see/agree....  Frustrating
> >> since there's really no "simple" way to determine this.
> >>
> >>>
> >>> The correct solution is:
> >>>
> >>>     - if chardev_tls is set to 1 and tls attribute is not configured in the XML
> >>>     the default after starting the domain should be tls=yes
> >>
> >> So IOW:
> >>
> >> +        if (cfg->chardevTLS &&
> >> +            dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES) {
> >>
> >> changes to
> >>
> >> +        if (cfg->chardevTLS &&
> >> +            dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {
> >>
> >> or (haveTLS == YES || haveTLS == ABSENT)
> >>
> >> This of course is essentially the logic from v6 which said disableTLS on
> >> a case by case basis.... All we have now is the positive form...
> >>
> >> So for both qemuBuildChrChardevStr and qemuDomainAttachChrDevice I'd
> >> have a similar change.  Does that suffice and do you need to see the change?
> > 
> > I think that we should reflect the state in live XML if the attribute exists.
> > 
> > Add a code to qemuProcessPrepareDomain() that will set dev->data.tcp.haveTLS
> > to config value if dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT and in
> > qemuBuildChrChardevStr() you can just check if
> > dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES.  This will also ensure that
> > the live XML contains the 'tls' attribute.  But make sure, that migration works
> > properly for all combinations.
> > 
> 
> I don't see the advantage... Altering the running domain would involve

The advantage is in case when the chardevTLS is set but the offline XML doesn't
have 'tls' attribute configured.  If the domain is started than it's perfectly
clear from the live XML that the tls is enabled or not.

> messing in qemuProcessAttach and setting the attribute for the domain if
> chardevTLS is set *BUT* how do we know without a bit of introspection if
> that domain was started with TLS and is using TLS? (IOW: looking at the
> running domain for tls-creds-x509). Additionally, someone could have

Well, we do that introspection and we must do it to properly detect what has
been used to start that domain.  The domain XML should reflect the current state
as closely as possible.

> changed the chardevTLS setting in qemu.conf after the domain was
> initially started and thus it wouldn't have it, so setting it blindly

Yes, someone can change the chardevTLS after the domain was started and it won't
break anything.  If the domain is destroyed and started again, everything works,
if the domain is saved and started again it will start with TLS encryption
enabled.  If someone removes certificates from qemu.conf and completely disable
TLS encryption and the domain was saved with TLS encryption configured it's
desirable that it should error out while restoring that domain.

> would probably have disastrous results.
> 
> Altering a domain definition during qemuProcessPrepareDomain (e.g.
> domain startup time) still has no way of determining if that domain had
> ever been started using TLS if it's not in the XML.

I don't understand why we need to know if the domain had ever been started using
TLS?  

> Finally, yeah migration is the final nail in the coffin for this. How
> does one migrate from 2.4 to 2.3 if 2.3 doesn't have this attribute we
> just quietly set to YES for them?

Well if the attribute is set to YES and the chardevTLS is set to 1 or if the
attribute is set to NO and chardevTLS is set to 0 we can safely remove the
attribute from migratable XML, because it's on user to ensure that the
configuration is properly set on both sides, for other cases that migration
should not be allowed because whether the encryption is enabled or not could be
changed.

Pavel

> I think the != NO is the safest solution (plus some adjustment to the
> formatdomain.html.in in order to describe this situation).
> 
> John
> 
> > I guess a another version would be better if you agree with exposing current
> > state into live XML.
> > 
> > Pavel
> > 
> >>>     - if chardev_tls is not set and tls attribute is not configured in the XML
> >>>     the default after starting the domain should be tls=no
> >>>
> >>
> >> We're not getting anywhere if chardev_tls is not set.
> >>
> >> John
> >>
> >> [...]
> >>
> >> --
> >> libvir-list mailing list
> >> libvir-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/libvir-list
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161014/a9aba6e7/attachment-0001.sig>


More information about the libvir-list mailing list