Re: [Qemu-devel] [PATCH for-2.9 v2] virtio-crypto: zeroize the key material before free

[Gonglei (Arei)]

Hi Max,

> 
> On 07.12.2016 03:29, Gonglei wrote:
> > Common practice with sensitive information (key material, passwords,
> > etc). Prevents sensitive information from being exposed by accident later in
> > coredumps, memory disclosure bugs when heap memory is reused, etc.
> >
> > Sensitive information is sometimes also held in mlocked pages to prevent
> > it being swapped to disk but that's not being done here.
> >
> > Let's zeroize the memory of CryptoDevBackendSymOpInfo structure pointed
> > for key material security.
> >
> > [v2: Stefan perfects the commit message, thanks]
> > Signed-off-by: Gonglei <address@hidden>
> > Reviewed-by: Stefan Hajnoczi <address@hidden>
> > ---
> >  hw/virtio/virtio-crypto.c | 13 ++++++++++++-
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> As far as I'm aware, other projects usually have a special memset
> variation for doing this. That is because compilers may choose to
> "optimize" memset(p, ...) + free(p) to just the free(p). Having a

Actually, I googled this, but I didn't find a definite answer. And

The Linux kernel uses kzfree instead of memset + kfree (mm/slab_common.c).

void kzfree(const void *p)
{
        size_t ks;
        void *mem = (void *)p;

        if (unlikely(ZERO_OR_NULL_PTR(mem)))
                return;
        ks = ksize(mem);
        memset(mem, 0, ks);
        kfree(mem);
}

Which is very similar with glib memory management IMO.

> special zeroizing function that the compiler cannot drop would prevent
> this. (By the way, C11 provides this functionality with memset_s().)
> 
> We are not using free() but g_free(), so the danger of a compiler
> detecting the pattern and "optimizing" it is probably much lower, but
> still, the possibility exists.
> 
Do we need to think about the compiler optimization here ? Or follow
what the linux kernel does.

Regards,
-Gonglei