mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2025-07-12 18:57:39 +03:00
icp: Use explicit_memset() exclusively in gcm_clear_ctx()
d634d20d1b
had been intended to fix a potential information leak issue where the compiler's optimization passes appeared to remove `memset()` operations that sanitize sensitive data before memory is freed for use by the rest of the kernel. When I wrote it, I had assumed that the compiler would not remove the other `memset()` operations, but upon reflection, I have realized that this was a bad assumption to make. I would rather have a very slight amount of additional overhead when calling `gcm_clear_ctx()` than risk a future compiler remove `memset()` calls. This is likely to happen if someone decides to try doing link time optimization and the person will not think to audit the assembly output for issues like this, so it is best to preempt the possibility before it happens. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Jorgen Lundman <lundman@lundman.net> Signed-off-by: Richard Yao <richard@ryao.dev> Closes #17343 (cherry picked from commitd8a33bc0a5
)
This commit is contained in:
parent
f28c685a84
commit
a4de1d38da
@ -173,12 +173,12 @@ gcm_clear_ctx(gcm_ctx_t *ctx)
|
||||
#if defined(CAN_USE_GCM_ASM)
|
||||
if (ctx->gcm_use_avx == B_TRUE) {
|
||||
ASSERT3P(ctx->gcm_Htable, !=, NULL);
|
||||
memset(ctx->gcm_Htable, 0, ctx->gcm_htab_len);
|
||||
explicit_memset(ctx->gcm_Htable, 0, ctx->gcm_htab_len);
|
||||
kmem_free(ctx->gcm_Htable, ctx->gcm_htab_len);
|
||||
}
|
||||
#endif
|
||||
if (ctx->gcm_pt_buf != NULL) {
|
||||
memset(ctx->gcm_pt_buf, 0, ctx->gcm_pt_buf_len);
|
||||
explicit_memset(ctx->gcm_pt_buf, 0, ctx->gcm_pt_buf_len);
|
||||
vmem_free(ctx->gcm_pt_buf, ctx->gcm_pt_buf_len);
|
||||
}
|
||||
/* Optional */
|
||||
|
Loading…
Reference in New Issue
Block a user