summaryrefslogtreecommitdiff
path: root/scripts/generate_rust_analyzer.py
diff options
context:
space:
mode:
authorMichael Kelley <mikelley@microsoft.com>2023-03-09 05:40:05 +0300
committerBorislav Petkov (AMD) <bp@alien8.de>2023-03-27 10:23:21 +0300
commitc7b5254bd802ee3868f1c59333545272dc700d6d (patch)
treeebecf38fb6074e6984b192fa56c6fb4f6a0d2af9 /scripts/generate_rust_analyzer.py
parentd33ddc92db8a61416473ff3d7f1c621c50733dc0 (diff)
downloadlinux-c7b5254bd802ee3868f1c59333545272dc700d6d.tar.xz
x86/mm: Handle decryption/re-encryption of bss_decrypted consistently
sme_postprocess_startup() decrypts the bss_decrypted section when sme_me_mask is non-zero. mem_encrypt_free_decrypted_mem() re-encrypts the unused portion based on CC_ATTR_MEM_ENCRYPT. In a Hyper-V guest VM using vTOM, these conditions are not equivalent as sme_me_mask is always zero when using vTOM. Consequently, mem_encrypt_free_decrypted_mem() attempts to re-encrypt memory that was never decrypted. So check sme_me_mask in mem_encrypt_free_decrypted_mem() too. Hyper-V guests using vTOM don't need the bss_decrypted section to be decrypted, so skipping the decryption/re-encryption doesn't cause a problem. Signed-off-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/1678329614-3482-5-git-send-email-mikelley@microsoft.com
Diffstat (limited to 'scripts/generate_rust_analyzer.py')
0 files changed, 0 insertions, 0 deletions