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 <arei.gong...@huawei.com>
> > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
> > ---
> > 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
