From: Tom Lendacky <thomas.lendacky@xxxxxxx> Sent: Wednesday, November 16, 2022 1:16 PM > > On 11/16/22 14:35, Tom Lendacky wrote: > > On 11/16/22 12:41, Michael Kelley wrote: > >> Current code in sme_postprocess_startup() decrypts the bss_decrypted > >> section when sme_me_mask is non-zero. But code in > >> mem_encrypt_free_decrytped_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. > >> > >> Fix this in mem_encrypt_free_decrypted_mem() by conditioning the > >> re-encryption on the same test for non-zero sme_me_mask. 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@xxxxxxxxxxxxx> > > Meant to add this in the previous reply... > > With the change to use sme_me_mask directly > > Reviewed-by: Tom Lendacky <thomas.lendacky@xxxxxxx> > Thanks for the reviews. And I see your point about sme_me_mask. I had not previously noticed that it is defined in the module, so no need to use a getter function. Michael
