Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit

From: Thomas HellstrÃm (VMware)
Date: Thu Sep 05 2019 - 11:21:39 EST


On 9/5/19 4:15 PM, Dave Hansen wrote:
Hi Thomas,

Thanks for the second batch of patches! These look much improved on all
fronts.

Yes, although the TTM functionality isn't in yet. Hopefully we won't have to bother you with those though, since this assumes TTM will be using the dma API.

On 9/5/19 3:35 AM, Thomas HellstrÃm (VMware) wrote:
-/* mprotect needs to preserve PAT bits when updating vm_page_prot */
+/*
+ * mprotect needs to preserve PAT and encryption bits when updating
+ * vm_page_prot
+ */
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
{
- pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
- pgprotval_t addbits = pgprot_val(newprot);
+ pgprotval_t preservebits = pgprot_val(oldprot) &
+ (_PAGE_CHG_MASK | sme_me_mask);
+ pgprotval_t addbits = pgprot_val(newprot) & ~sme_me_mask;
return __pgprot(preservebits | addbits);
}
_PAGE_CHG_MASK is claiming similar functionality about preserving bits
when changing PTEs:

/*
* Set of bits not changed in pte_modify. The pte's
* protection key is treated like _PAGE_RW, for
* instance, and is *not* included in this mask since
* pte_modify() does modify it.
*/
#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \
_PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
_PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
This makes me wonder if we should be including sme_me_mask in
_PAGE_CHG_MASK (logically).

I was thinking the same. But what confuses me is that addbits isn't masked with ~_PAGE_CHG_MASK, which is needed for sme_me_mask, since the problem otherwise is typically that the encryption bit is incorrectly set in addbits. I wonder whether it's an optimization or intentional.

/Thomas