2020-09-11 11:47:34

by Alex Dewar

[permalink] [raw]
Subject: [PATCH] security: keys: Use kvfree_sensitive in a few places

In big_key.c, there are a few places where memzero_explicit + kvfree is
used. It is better to use kvfree_sensitive instead, which is more
readable and also prevents the compiler from eliding the call to
memzero_explicit. Fix this.

Signed-off-by: Alex Dewar <[email protected]>
---
security/keys/big_key.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 691347dea3c1..d17e5f09eeb8 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -121,8 +121,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
*path = file->f_path;
path_get(path);
fput(file);
- memzero_explicit(buf, enclen);
- kvfree(buf);
+ kvfree_sensitive(buf, enclen);
} else {
/* Just store the data in a buffer */
void *data = kmalloc(datalen, GFP_KERNEL);
@@ -140,8 +139,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
err_enckey:
kfree_sensitive(enckey);
error:
- memzero_explicit(buf, enclen);
- kvfree(buf);
+ kvfree_sensitive(buf, enclen);
return ret;
}

@@ -273,8 +271,7 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)
err_fput:
fput(file);
error:
- memzero_explicit(buf, enclen);
- kvfree(buf);
+ kvfree_sensitive(buf, enclen);
} else {
ret = datalen;
memcpy(buffer, key->payload.data[big_key_data], datalen);
--
2.28.0


2020-09-11 16:10:42

by Denis Efremov

[permalink] [raw]
Subject: Re: [PATCH] security: keys: Use kvfree_sensitive in a few places

Hi,

same patch

https://lkml.org/lkml/2020/8/27/168

Thanks,
Denis

On 9/11/20 2:44 PM, Alex Dewar wrote:
> In big_key.c, there are a few places where memzero_explicit + kvfree is
> used. It is better to use kvfree_sensitive instead, which is more
> readable and also prevents the compiler from eliding the call to
> memzero_explicit. Fix this.
>
> Signed-off-by: Alex Dewar <[email protected]>
> ---
> security/keys/big_key.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/security/keys/big_key.c b/security/keys/big_key.c
> index 691347dea3c1..d17e5f09eeb8 100644
> --- a/security/keys/big_key.c
> +++ b/security/keys/big_key.c
> @@ -121,8 +121,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
> *path = file->f_path;
> path_get(path);
> fput(file);
> - memzero_explicit(buf, enclen);
> - kvfree(buf);
> + kvfree_sensitive(buf, enclen);
> } else {
> /* Just store the data in a buffer */
> void *data = kmalloc(datalen, GFP_KERNEL);
> @@ -140,8 +139,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
> err_enckey:
> kfree_sensitive(enckey);
> error:
> - memzero_explicit(buf, enclen);
> - kvfree(buf);
> + kvfree_sensitive(buf, enclen);
> return ret;
> }
>
> @@ -273,8 +271,7 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)
> err_fput:
> fput(file);
> error:
> - memzero_explicit(buf, enclen);
> - kvfree(buf);
> + kvfree_sensitive(buf, enclen);
> } else {
> ret = datalen;
> memcpy(buffer, key->payload.data[big_key_data], datalen);
>

2020-09-11 16:13:04

by Alex Dewar

[permalink] [raw]
Subject: Re: [PATCH] security: keys: Use kvfree_sensitive in a few places

On 2020-09-11 17:05, Denis Efremov wrote:
> Hi,
>
> same patch
>
> https://lkml.org/lkml/2020/8/27/168
>
> Thanks,
> Denis
Ah ok. Sorry for the noise!
>
> On 9/11/20 2:44 PM, Alex Dewar wrote:
>> In big_key.c, there are a few places where memzero_explicit + kvfree is
>> used. It is better to use kvfree_sensitive instead, which is more
>> readable and also prevents the compiler from eliding the call to
>> memzero_explicit. Fix this.
>>
>> Signed-off-by: Alex Dewar <[email protected]>
>> ---
>> security/keys/big_key.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/security/keys/big_key.c b/security/keys/big_key.c
>> index 691347dea3c1..d17e5f09eeb8 100644
>> --- a/security/keys/big_key.c
>> +++ b/security/keys/big_key.c
>> @@ -121,8 +121,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
>> *path = file->f_path;
>> path_get(path);
>> fput(file);
>> - memzero_explicit(buf, enclen);
>> - kvfree(buf);
>> + kvfree_sensitive(buf, enclen);
>> } else {
>> /* Just store the data in a buffer */
>> void *data = kmalloc(datalen, GFP_KERNEL);
>> @@ -140,8 +139,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
>> err_enckey:
>> kfree_sensitive(enckey);
>> error:
>> - memzero_explicit(buf, enclen);
>> - kvfree(buf);
>> + kvfree_sensitive(buf, enclen);
>> return ret;
>> }
>>
>> @@ -273,8 +271,7 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)
>> err_fput:
>> fput(file);
>> error:
>> - memzero_explicit(buf, enclen);
>> - kvfree(buf);
>> + kvfree_sensitive(buf, enclen);
>> } else {
>> ret = datalen;
>> memcpy(buffer, key->payload.data[big_key_data], datalen);
>>

2020-09-11 16:58:57

by James Bottomley

[permalink] [raw]
Subject: Re: [PATCH] security: keys: Use kvfree_sensitive in a few places

On Fri, 2020-09-11 at 12:44 +0100, Alex Dewar wrote:
> In big_key.c, there are a few places where memzero_explicit + kvfree
> is used. It is better to use kvfree_sensitive instead, which is more
> readable and also prevents the compiler from eliding the call to
> memzero_explicit. Fix this.

That last bit is untrue: the compiler can't elide memzero_explicit ...
that's why it has the explicit suffix.

The original problem was a lot of people do memset(.., 0, ..); kfree()
which the compiler can elide if it understands the memory is going out
of scope. Or the even more problematic memset(..., 0, ...) on a stack
variable before it goes out of scope.

We can argue about readability but there's no secret leak here.

James

2020-09-14 18:08:13

by Jarkko Sakkinen

[permalink] [raw]
Subject: Re: [PATCH] security: keys: Use kvfree_sensitive in a few places

On Fri, Sep 11, 2020 at 07:05:16PM +0300, Denis Efremov wrote:
> Hi,
>
> same patch
>
> https://lkml.org/lkml/2020/8/27/168
>
> Thanks,
> Denis

David, can you pick this up?

/Jarkko