<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/crypto/ccp, branch v5.10.78</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>crypto: ccp - fix resource leaks in ccp_run_aes_gcm_cmd()</title>
<updated>2021-10-06T13:56:03+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-08-26T13:04:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=17ccc64e4fa5d3673528474bfeda814d95dc600a'/>
<id>17ccc64e4fa5d3673528474bfeda814d95dc600a</id>
<content type='text'>
commit 505d9dcb0f7ddf9d075e729523a33d38642ae680 upstream.

There are three bugs in this code:

1) If we ccp_init_data() fails for &amp;src then we need to free aad.
   Use goto e_aad instead of goto e_ctx.
2) The label to free the &amp;final_wa was named incorrectly as "e_tag" but
   it should have been "e_final_wa".  One error path leaked &amp;final_wa.
3) The &amp;tag was leaked on one error path.  In that case, I added a free
   before the goto because the resource was local to that block.

Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Reported-by: "minihanshen(沈明航)" &lt;minihanshen@tencent.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: John Allen &lt;john.allen@amd.com&gt;
Tested-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 505d9dcb0f7ddf9d075e729523a33d38642ae680 upstream.

There are three bugs in this code:

1) If we ccp_init_data() fails for &amp;src then we need to free aad.
   Use goto e_aad instead of goto e_ctx.
2) The label to free the &amp;final_wa was named incorrectly as "e_tag" but
   it should have been "e_final_wa".  One error path leaked &amp;final_wa.
3) The &amp;tag was leaked on one error path.  In that case, I added a free
   before the goto because the resource was local to that block.

Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Reported-by: "minihanshen(沈明航)" &lt;minihanshen@tencent.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: John Allen &lt;john.allen@amd.com&gt;
Tested-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - shutdown SEV firmware on kexec</title>
<updated>2021-09-18T11:40:09+00:00</updated>
<author>
<name>Brijesh Singh</name>
<email>brijesh.singh@amd.com</email>
</author>
<published>2021-07-28T15:15:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6cae39f457547623fe1a48370d87cc1f4125fc42'/>
<id>6cae39f457547623fe1a48370d87cc1f4125fc42</id>
<content type='text'>
commit 5441a07a127f106c9936e4f9fa1a8a93e3f31828 upstream.

The commit 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the
PSP driver") added support to allocate Trusted Memory Region (TMR)
used during the SEV-ES firmware initialization. The TMR gets locked
during the firmware initialization and unlocked during the shutdown.
While the TMR is locked, access to it is disallowed.

Currently, the CCP driver does not shutdown the firmware during the
kexec reboot, leaving the TMR memory locked.

Register a callback to shutdown the SEV firmware on the kexec boot.

Fixes: 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver")
Reported-by: Lucas Nussbaum &lt;lucas.nussbaum@inria.fr&gt;
Tested-by: Lucas Nussbaum &lt;lucas.nussbaum@inria.fr&gt;
Cc: &lt;stable@kernel.org&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Joerg Roedel &lt;jroedel@suse.de&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5441a07a127f106c9936e4f9fa1a8a93e3f31828 upstream.

The commit 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the
PSP driver") added support to allocate Trusted Memory Region (TMR)
used during the SEV-ES firmware initialization. The TMR gets locked
during the firmware initialization and unlocked during the shutdown.
While the TMR is locked, access to it is disallowed.

Currently, the CCP driver does not shutdown the firmware during the
kexec reboot, leaving the TMR memory locked.

Register a callback to shutdown the SEV firmware on the kexec boot.

Fixes: 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver")
Reported-by: Lucas Nussbaum &lt;lucas.nussbaum@inria.fr&gt;
Tested-by: Lucas Nussbaum &lt;lucas.nussbaum@inria.fr&gt;
Cc: &lt;stable@kernel.org&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Joerg Roedel &lt;jroedel@suse.de&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Fix a resource leak in an error handling path</title>
<updated>2021-07-14T14:56:04+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2021-05-16T06:58:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a9d02976e9bac2232f6d09dde77ccff7db105521'/>
<id>a9d02976e9bac2232f6d09dde77ccff7db105521</id>
<content type='text'>
[ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ]

If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be
called as already done in the error handling path.

Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ]

If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be
called as already done in the error handling path.

Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Annotate SEV Firmware file names</title>
<updated>2021-07-14T14:55:39+00:00</updated>
<author>
<name>Joerg Roedel</name>
<email>jroedel@suse.de</email>
</author>
<published>2021-04-26T08:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=123c1b05b0073cd999064ddc82d1e44bd9aadc7a'/>
<id>123c1b05b0073cd999064ddc82d1e44bd9aadc7a</id>
<content type='text'>
commit c8671c7dc7d51125ab9f651697866bf4a9132277 upstream.

Annotate the firmware files CCP might need using MODULE_FIRMWARE().
This will get them included into an initrd when CCP is also included
there. Otherwise the CCP module will not find its firmware when loaded
before the root-fs is mounted.
This can cause problems when the pre-loaded SEV firmware is too old to
support current SEV and SEV-ES virtualization features.

Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model")
Cc: stable@vger.kernel.org # v4.20+
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c8671c7dc7d51125ab9f651697866bf4a9132277 upstream.

Annotate the firmware files CCP might need using MODULE_FIRMWARE().
This will get them included into an initrd when CCP is also included
there. Otherwise the CCP module will not find its firmware when loaded
before the root-fs is mounted.
This can cause problems when the pre-loaded SEV firmware is too old to
support current SEV and SEV-ES virtualization features.

Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model")
Cc: stable@vger.kernel.org # v4.20+
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp: Free SEV device if SEV init fails</title>
<updated>2021-05-19T08:12:58+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2021-04-06T22:49:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3a5dee0f30c898cc9273265d5f5b6bac94d49e8'/>
<id>f3a5dee0f30c898cc9273265d5f5b6bac94d49e8</id>
<content type='text'>
[ Upstream commit b61a9071dc72a3c709192c0c00ab87c2b3de1d94 ]

Free the SEV device if later initialization fails.  The memory isn't
technically leaked as it's tracked in the top-level device's devres
list, but unless the top-level device is removed, the memory won't be
freed and is effectively leaked.

Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-Id: &lt;20210406224952.4177376-2-seanjc@google.com&gt;
Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b61a9071dc72a3c709192c0c00ab87c2b3de1d94 ]

Free the SEV device if later initialization fails.  The memory isn't
technically leaked as it's tracked in the top-level device's devres
list, but unless the top-level device is removed, the memory won't be
freed and is effectively leaked.

Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-Id: &lt;20210406224952.4177376-2-seanjc@google.com&gt;
Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp: Detect and reject "invalid" addresses destined for PSP</title>
<updated>2021-05-14T07:50:41+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2021-04-06T22:49:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e606073b77a3c4a6f3f6b013deef36f75aef5737'/>
<id>e606073b77a3c4a6f3f6b013deef36f75aef5737</id>
<content type='text'>
[ Upstream commit 74c1f1366eb7714b8b211554f6c5cee315ff3fbc ]

Explicitly reject using pointers that are not virt_to_phys() friendly
as the source for SEV commands that are sent to the PSP.  The PSP works
with physical addresses, and __pa()/virt_to_phys() will not return the
correct address in these cases, e.g. for a vmalloc'd pointer.  At best,
the bogus address will cause the command to fail, and at worst lead to
system instability.

While it's unlikely that callers will deliberately use a bad pointer for
SEV buffers, a caller can easily use a vmalloc'd pointer unknowingly when
running with CONFIG_VMAP_STACK=y as it's not obvious that putting the
command buffers on the stack would be bad.  The command buffers are
relative  small and easily fit on the stack, and the APIs to do not
document that the incoming pointer must be a physically contiguous,
__pa() friendly pointer.

Cc: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-Id: &lt;20210406224952.4177376-3-seanjc@google.com&gt;
Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 74c1f1366eb7714b8b211554f6c5cee315ff3fbc ]

Explicitly reject using pointers that are not virt_to_phys() friendly
as the source for SEV commands that are sent to the PSP.  The PSP works
with physical addresses, and __pa()/virt_to_phys() will not return the
correct address in these cases, e.g. for a vmalloc'd pointer.  At best,
the bogus address will cause the command to fail, and at worst lead to
system instability.

While it's unlikely that callers will deliberately use a bad pointer for
SEV buffers, a caller can easily use a vmalloc'd pointer unknowingly when
running with CONFIG_VMAP_STACK=y as it's not obvious that putting the
command buffers on the stack would be bad.  The command buffers are
relative  small and easily fit on the stack, and the APIs to do not
document that the incoming pointer must be a physically contiguous,
__pa() friendly pointer.

Cc: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-Id: &lt;20210406224952.4177376-3-seanjc@google.com&gt;
Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - fix command queuing to TEE ring buffer</title>
<updated>2021-05-14T07:50:11+00:00</updated>
<author>
<name>Rijo Thomas</name>
<email>Rijo-john.Thomas@amd.com</email>
</author>
<published>2021-03-15T08:25:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=31e1314ceee0f8e5da7067383ef0317ef50a4ab4'/>
<id>31e1314ceee0f8e5da7067383ef0317ef50a4ab4</id>
<content type='text'>
[ Upstream commit 00aa6e65aa04e500a11a2c91e92a11c37b9e234d ]

Multiple threads or clients can submit a command to the TEE ring
buffer. This patch helps to synchronize command submission to the
ring.

One thread shall write a command to a TEE ring buffer entry only if:

 - Trusted OS has notified that the TEE command for the given entry
   has been processed and driver has copied the TEE response into
   client buffer.

 - The command entry is empty and can be written into.

After a command has been written to the TEE ring buffer, the global
wptr (mutex protected) shall be incremented for use by next client.

If PSP became unresponsive while processing TEE request from a
client, then further command submission to queue will be disabled.

Fixes: 33960acccfbd (crypto: ccp - add TEE support for Raven Ridge)
Reviewed-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;
Signed-off-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 00aa6e65aa04e500a11a2c91e92a11c37b9e234d ]

Multiple threads or clients can submit a command to the TEE ring
buffer. This patch helps to synchronize command submission to the
ring.

One thread shall write a command to a TEE ring buffer entry only if:

 - Trusted OS has notified that the TEE command for the given entry
   has been processed and driver has copied the TEE response into
   client buffer.

 - The command entry is empty and can be written into.

After a command has been written to the TEE ring buffer, the global
wptr (mutex protected) shall be incremented for use by next client.

If PSP became unresponsive while processing TEE request from a
client, then further command submission to queue will be disabled.

Fixes: 33960acccfbd (crypto: ccp - add TEE support for Raven Ridge)
Reviewed-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;
Signed-off-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - fix error handling</title>
<updated>2020-10-02T08:02:10+00:00</updated>
<author>
<name>Pavel Machek</name>
<email>pavel@denx.de</email>
</author>
<published>2020-09-21T11:34:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e356c49c6cf0db3f00e1558749170bd56e47652d'/>
<id>e356c49c6cf0db3f00e1558749170bd56e47652d</id>
<content type='text'>
Fix resource leak in error handling.

Signed-off-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix resource leak in error handling.

Signed-off-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: algapi - Remove skbuff.h inclusion</title>
<updated>2020-08-20T04:04:28+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2020-08-19T11:58:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0c3dc787a62aef3ca7aedf3797ec42fff9b0a913'/>
<id>0c3dc787a62aef3ca7aedf3797ec42fff9b0a913</id>
<content type='text'>
The header file algapi.h includes skbuff.h unnecessarily since
all we need is a forward declaration for struct sk_buff.  This
patch removes that inclusion.

Unfortunately skbuff.h pulls in a lot of things and drivers over
the years have come to rely on it so this patch adds a lot of
missing inclusions that result from this.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The header file algapi.h includes skbuff.h unnecessarily since
all we need is a forward declaration for struct sk_buff.  This
patch removes that inclusion.

Unfortunately skbuff.h pulls in a lot of things and drivers over
the years have come to rely on it so this patch adds a lot of
missing inclusions that result from this.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm, treewide: rename kzfree() to kfree_sensitive()</title>
<updated>2020-08-07T18:33:22+00:00</updated>
<author>
<name>Waiman Long</name>
<email>longman@redhat.com</email>
</author>
<published>2020-08-07T06:18:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=453431a54934d917153c65211b2dabf45562ca88'/>
<id>453431a54934d917153c65211b2dabf45562ca88</id>
<content type='text'>
As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Waiman Long &lt;longman@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: James Morris &lt;jmorris@namei.org&gt;
Cc: "Serge E. Hallyn" &lt;serge@hallyn.com&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: "Jason A . Donenfeld" &lt;Jason@zx2c4.com&gt;
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Waiman Long &lt;longman@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: James Morris &lt;jmorris@namei.org&gt;
Cc: "Serge E. Hallyn" &lt;serge@hallyn.com&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: "Jason A . Donenfeld" &lt;Jason@zx2c4.com&gt;
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
