qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH for-2.9 v2] virtio-crypto: zeroize the key material before free
Date: Sat, 10 Dec 2016 15:56:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 10.12.2016 03:58, Gonglei (Arei) wrote:
>>
>>
>> On 09.12.2016 02:42, Gonglei (Arei) wrote:
>>> Hi,
>>>
>>>>
>>>> Subject: Re: [Qemu-devel] [PATCH for-2.9 v2] virtio-crypto: zeroize the key
>>>> material before free
>>>>
>>>> On 08.12.2016 16:23, Eric Blake wrote:
>>>>> On 12/07/2016 08:28 PM, Gonglei (Arei) wrote:
>>>>>
>>>>>>> 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).
>>>>
>>>> Well, I personally don't mind whether we use a custom zfree() or a
>>>> custom memset_s() + free(). I only mind that this patch actually always
>>>> does what it is intended to do.
>>>>
>>> Yes, but why linux kernel to think about the compiler optimization for
>>> memset for sensitive data?
>>
>> I'm afraid I don't quite (syntactically) understand this question. Do
>> you mean to ask why the Linux kernel would have to think about this
>> optimization? My answer to that would be because the optimization of
>> memset() + free() is known, and they probably want to protect against
>> the compiler optimizing it even with -ffreestanding and differently
>> called functions -- you never know.
>>
> Sorry, that's my typo. ;) 
> 
> My question is why not linux kernel to think about the compiler optimization
> on the code layer. Because the realization of kzfree is just memset + kfree, 
> it didn't add any memory barrier to prevent memset is optimized, or use
> secure_memset, or whatever.
> 
> So you answer means they maybe use some compiler options to avoid
> the compiler optimizing?

Yes, maybe they are trusting that using -ffreestanding will keep the
compiler from optimizing the combination. I personally wouldn't trust
that, because I have seen gcc ignore that convention and just optimize
anyway, but I'm not Linus and I guess if Linus complains about gcc
breaking something, it will be fixed much more quickly than when I do.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]