> -----Original Message-----
> From: Denis Efremov <[email protected]>
> Sent: Friday, September 4, 2020 10:55 AM
> To: Van Leeuwen, Pascal <[email protected]>; [email protected]
> Cc: Corentin Labbe <[email protected]>; Herbert Xu <[email protected]>; [email protected]
> Subject: Re: [PATCH v2 1/4] crypto: inside-secure - use kfree_sensitive()
>
> <<< External Email >>>
> Hi,
>
> On 9/2/20 4:10 PM, Van Leeuwen, Pascal wrote:
> >> -----Original Message-----
> >> From: [email protected] <[email protected]> On Behalf Of Denis Efremov
> >> Sent: Thursday, August 27, 2020 8:44 AM
> >> To: [email protected]
> >> Cc: Denis Efremov <[email protected]>; Corentin Labbe <[email protected]>; Herbert Xu
> >> <[email protected]>; [email protected]
> >> Subject: [PATCH v2 1/4] crypto: inside-secure - use kfree_sensitive()
> >>
> >> <<< External Email >>>
> >> Use kfree_sensitive() instead of open-coding it.
> >>
> >> Signed-off-by: Denis Efremov <[email protected]>
> >> ---
> >> drivers/crypto/inside-secure/safexcel_hash.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/crypto/inside-secure/safexcel_hash.c b/drivers/crypto/inside-secure/safexcel_hash.c
> >> index 16a467969d8e..5ffdc1cd5847 100644
> >> --- a/drivers/crypto/inside-secure/safexcel_hash.c
> >> +++ b/drivers/crypto/inside-secure/safexcel_hash.c
> >> @@ -1082,8 +1082,7 @@ static int safexcel_hmac_init_pad(struct ahash_request *areq,
> >> }
> >>
> >> /* Avoid leaking */
> >> -memzero_explicit(keydup, keylen);
> >> -kfree(keydup);
> >> +kfree_sensitive(keydup);
> >>
> > I'm not sure here ... I verified it does not break the driver (not a big surprise), but ...
> >
> > memzero_explicit guarantees that it will not get optimized away and the keydata _always_
> > gets overwritten. Does kfree_sensitive also come with such a guarantee? I could not find a
> > hard statement on that in its documentation. Although the "sensitive" part surely suggests
> > it.
>
> kfree_sensitive() uses memzero_explicit() internally.
>
Ok. Although formally that's still only _current_ implementation.
But given the function name, I guess it's a fair assumption that the intention is to maintain
this behavior going forward.
> > Additionally, this remark is made in the documentation for kfree_sensitive: "this function
> > zeroes the whole allocated buffer which can be a good deal bigger than the requested buffer
> > size passed to kmalloc(). So be careful when using this function in performance sensitive
> > code"
> >
> > While the memzero_explicit does not zeroize anything beyond keylen.
> > Which is all you really need here, so why would you want to zeroize potentially a lot more?
> > In any case the two are not fully equivalent.
>
> There are a number of predefined allocation sizes (power of 2) for faster alloc,
> i.e. https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L349
> and it looks like that keys we free in this patches are in bounds of these sizes.
> As far as I understand, if a key is not a power of 2 len, the buffer will be zeroed to the closest
> power of 2 size.
>
This path is for hash keys that are larger than the hash block size. Potentially, there is no
upper bound on the size of such a hash key, so it doesn't need to be in that range hence
zeroizing to the next power of 2 boundary could be expensive.
OTOH, I don't expect this path to be frequently used, and the key processing itself already
costs a lot of time, so it's probably not that relevant. Never mind.
I guess was more about whether using kfree_sensitive() is a good replacement _in general_.
For that, there should be some guaranteed upper bound on how much extra will be zeroized.
Given the above considerations (and after testing this on my hardware):
Tested-by: Pascal van Leeuwen <[email protected]>
> For small sizes like these, performance difference should be unnoticeable because
> of cache lines and how arch-optimized memzero() works. Key freeing doesn't look like a frequent event.
>
> Thanks,
> Denis
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>