On Thu, 2019-08-22 at 02:01 +0300, Nir Soffer wrote:
> On Wed, Aug 14, 2019, 23:23 Maxim Levitsky <mlevi...@redhat.com> wrote:
>
> > While there are other places where these are still stored in memory,
> > this is still one less key material area that can be sniffed with
> > various side channel attacks
> >
> >
> >
> > Signed-off-by: Maxim Levitsky <mlevi...@redhat.com>
> > ---
> > crypto/block-luks.c | 52 ++++++++++++++++++++++++++++++++++++++-------
> > 1 file changed, 44 insertions(+), 8 deletions(-)
> >
> > diff --git a/crypto/block-luks.c b/crypto/block-luks.c
> > index e1a4df94b7..336e633df4 100644
> > --- a/crypto/block-luks.c
> > +++ b/crypto/block-luks.c
> > @@ -1023,8 +1023,18 @@ qcrypto_block_luks_load_key(QCryptoBlock *block,
> > cleanup:
> > qcrypto_ivgen_free(ivgen);
> > qcrypto_cipher_free(cipher);
> > - g_free(splitkey);
> > - g_free(possiblekey);
> > +
> > + if (splitkey) {
> > + memset(splitkey, 0, splitkeylen);
> >
>
> I think we need memset_s() or similar replacement, see
>
> https://www.cryptologie.net/article/419/zeroing-memory-compiler-optimizations-and-memset_s/
You raise a very very good point here! Thanks!!
Best regards,
Maxim Levitsky
