[PATCH 07/11] libxlMakeNetworkDiskSrc: Don't bother with secure erase of secrets

Daniel P. Berrangé berrange at redhat.com
Mon Dec 12 16:00:09 UTC 2022


On Mon, Dec 12, 2022 at 03:37:08PM +0100, Peter Krempa wrote:
> On Mon, Dec 12, 2022 at 09:12:15 +0000, Daniel P. Berrangé wrote:
> > On Fri, Dec 09, 2022 at 05:28:59PM +0100, Peter Krempa wrote:
> > > The contents of both 'secret' and 'base64secret' are part of different
> > > buffers wich are not erased securely. Don't bother with virSecureErase*.
> > 
> > Again, just because other code isn't right, doesn't mean we should
> > delete this. Make the other buffer be erased securely instead.
> 
> In many cases such as this one the secret is formatted into a buffer
> that may be realloc'd while it's being constructed while the secret is
> inside.

snip

> Thus ... for buffers where realloc is in use, the attempt to clear it
> afterwards is basically equivalent in not clearing the buffer before
> freeing it.

That is very true, but it would be possible to address this limitation
by avoiding use of realloc in targetted places such as this.  For example,
we could initialize the virBuffer with  g_string_sized_new(1024) to
preallocate 1024 bytes, which would make realloc pretty unlikely to
happen in any normal config.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list