On Tue, 11/03 07:35, Daniel P. Berrange wrote: > On Tue, Nov 03, 2015 at 03:01:16PM +0800, Fam Zheng wrote: > > This would be a safer channel when we want to provide block options that > > contain sensitive information, such as fields for authentication. > > If passing of security sensitive data is the motivation for this, > then I don't think we want it really. This approach merely avoids > the config being visible in the process listing, which is really just > one problem. When people file bugs they are going to need to provide > the block device config, and that still going to contain sensitive > info and thus leak. Similarly apps generating block config like libvirt > are still going to be logging the block config they generate, which is > again going to leak secrets. Finally, we need the ability to pass > security sensitive data to QEMU in many other areas besides block devices > so need a more general mechanism > > I've proposed a way to provide secrets to QEMU in a way that is > usable across all QEMU backends, that I think is a much better > approach because it totally decouples the sensitive data from > the rest of the config data, rather than having it inline > > https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04365.html >
Apparently I've overlooked your post, thanks for pointing out. I think your solution covers everything this series has to do. Fam