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

On Fri, Oct 14, 2016 at 03:49:13PM -0400, John Ferlan wrote: > > > On 10/14/2016 11:30 AM, Pavel Hrdina wrote: >> 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. >> > > Maybe I didn't explain it well enough... I don't see the advantage of > modifying qemuProcessPrepareDomain or qemuProcessAttach to try and > determine whether we should "enable" this property. I see no need to > introspect to inspect a setting in order to then make some assumption > whether the property should be enabled or not. We'll get ourselves in > trouble doing so. Too much complexity, too much danger for making a bad > assumption or decision.

There is a small complexity but noting danger and nothing slick - in qemuProcessPrepareDomain: if (dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT) { dev->data.tcp.haveTLS = cfg->chardevTLS; dev->data.tcp.tlsFromConfig = true; } - in qemuProcessAttach: the detection of TCP chardev is broken and doesn't even work, but if someone fix it than it's also simple if (opt && strstr(opt, "tls-creds")) dev->data.tcp.haveTLS = true;

NOTE: this domain was executed outside of libvirt so it was not based on config - in virDomainChrSourceDefParseXML: add code to parse "fromConfig" if (flags & VIR_DOMAIN_DEF_PARSE_STATUS) - in virDomainChrSourceDefFormat: if (def->data.tcp.haveTLS != VIR_TRISTATE_BOOL_ABSENT && !(flags & VIR_DOMAIN_DEF_FORMAT_MIGRATABLE && def->data.tcp.tlsFromConfig)) virBufferAsprintf(buf, " tls='%s'", virTristateBoolTypeToString(def->data.tcp.haveTLS)); if (flags & VIR_DOMAIN_DEF_FORMAT_STATUS) virBufferAsprintf(buf, " fromConfig='%d'", def->data.tcp.tlsFromConfig); I can see that someone may not like this approach, but this is how it works in libvirt. It's our mess that we introduce a feature and in next release we introduce an attribute to control/reflect that feature via XML.

Try to look at it from user POV, there is a config option that can enable TLS encryption for all domains and all chardevs, but there is also 'tls' attribute that can be used to disable TLS encryption if it's set in qemu.conf or enable TLS encryption if only proper certificates are set in qemu.conf. So if someone looks at the live XML, if there is an 'tls' attribute, it's clear, but if the attribute is missing, I would have to remember/check some different place to see whether TLS encryption is configured or not. I would not like this and I would asking a question why libvirt cannot reflect this case in live XML?

[...] >>> 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. > > I think avoiding touching the migration XML is far more important than > trying to figure out all the possible permutations in order to come up > with some slick way to modify XML on the fly. I don't agree and we already do a lot of stuff to create a proper migratable XML that is backward compatible if no new feature was used. Unfortunately the 'tls' attribute isn't a new feature, the feature already exists in previous libvirt release and therefore we have to handle it properly to not break migration.