| Message ID | 20180717112029.42378-10-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote: > An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way > we don't need to do anything special to setup encrypted page table > entries We don't do anything special for protection keys, either. They just work too. > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > index 99fff853c944..3731f7e08757 100644 > --- a/arch/x86/include/asm/pgtable_types.h > +++ b/arch/x86/include/asm/pgtable_types.h > @@ -120,8 +120,21 @@ > * protection key is treated like _PAGE_RW, for > * instance, and is *not* included in this mask since > * pte_modify() does modify it. > + * > + * They include the physical address and the memory encryption keyID. > + * The paddr and the keyID never occupy the same bits at the same time. > + * But, a given bit might be used for the keyID on one system and used for > + * the physical address on another. As an optimization, we manage them in > + * one unit here since their combination always occupies the same hardware > + * bits. PTE_PFN_MASK_MAX stores combined mask. > + * > + * Cast PAGE_MASK to a signed type so that it is sign-extended if > + * virtual addresses are 32-bits but physical addresses are larger > + * (ie, 32-bit PAE). > */ Could you please make the comment block consistent? You're a lot wider than the comment above. > -#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ > +#define PTE_PFN_MASK_MAX \ > + (((signed long)PAGE_MASK) & ((1ULL << __PHYSICAL_MASK_SHIFT) - 1)) > +#define _PAGE_CHG_MASK (PTE_PFN_MASK_MAX | _PAGE_PCD | _PAGE_PWT | \ > _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ > _PAGE_SOFT_DIRTY) Man, I'm not a fan of this. This saves us from consuming 6 VM_HIGH bits (which we are not short on). But, at the cost of complexity. Protection keys eat up PTE space and have an interface called pkey_mprotect(). MKTME KeyIDs take up PTE space and will probably have an interface called something_mprotect(). Yet, the implementations are going to be _very_ different with pkeys being excluded from _PAGE_CHG_MASK and KeyIDs being included. I think you're saved here because we don't _actually_ do pte_modify() on an existing PTE: we blow the old one away upon encrypted_mprotect() and replace the PTE with a new one. But, this is incompatible with any case where we want to change the KeyID and keep the old PTE target. With AES-XTS, I guess this is a safe assumption, but it's worrying. Are there scenarios where we want to keep PTE contents, but change the KeyID?
On Wed, Jul 18, 2018 at 04:30:35PM -0700, Dave Hansen wrote: > On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote: > > An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way > > we don't need to do anything special to setup encrypted page table > > entries > > We don't do anything special for protection keys, either. They just > work too. > > > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > > index 99fff853c944..3731f7e08757 100644 > > --- a/arch/x86/include/asm/pgtable_types.h > > +++ b/arch/x86/include/asm/pgtable_types.h > > @@ -120,8 +120,21 @@ > > * protection key is treated like _PAGE_RW, for > > * instance, and is *not* included in this mask since > > * pte_modify() does modify it. > > + * > > + * They include the physical address and the memory encryption keyID. > > + * The paddr and the keyID never occupy the same bits at the same time. > > + * But, a given bit might be used for the keyID on one system and used for > > + * the physical address on another. As an optimization, we manage them in > > + * one unit here since their combination always occupies the same hardware > > + * bits. PTE_PFN_MASK_MAX stores combined mask. > > + * > > + * Cast PAGE_MASK to a signed type so that it is sign-extended if > > + * virtual addresses are 32-bits but physical addresses are larger > > + * (ie, 32-bit PAE). > > */ > > Could you please make the comment block consistent? You're a lot wider > than the comment above. Okay. > > -#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ > > +#define PTE_PFN_MASK_MAX \ > > + (((signed long)PAGE_MASK) & ((1ULL << __PHYSICAL_MASK_SHIFT) - 1)) > > +#define _PAGE_CHG_MASK (PTE_PFN_MASK_MAX | _PAGE_PCD | _PAGE_PWT | \ > > _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ > > _PAGE_SOFT_DIRTY) > > Man, I'm not a fan of this. This saves us from consuming 6 VM_HIGH bits > (which we are not short on). But, at the cost of complexity. 15, not 6. We have up-to 15 KeyID bits architecturally. We can just have a separate field in vm_area_struct if we must. But vm_page_prot work fine so far. I don't see a big reasone to change them. > Protection keys eat up PTE space and have an interface called > pkey_mprotect(). MKTME KeyIDs take up PTE space and will probably have > an interface called something_mprotect(). Yet, the implementations are > going to be _very_ different with pkeys being excluded from > _PAGE_CHG_MASK and KeyIDs being included. > > I think you're saved here because we don't _actually_ do pte_modify() on > an existing PTE: we blow the old one away upon encrypted_mprotect() and > replace the PTE with a new one. > > But, this is incompatible with any case where we want to change the > KeyID and keep the old PTE target. With AES-XTS, I guess this is a safe > assumption, but it's worrying. > > Are there scenarios where we want to keep PTE contents, but change the > KeyID? I don't see such scenario. If for some reason we would need to map the same memory with different KeyID it can be done from scratch. Without modifing existing mapping.
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 99fff853c944..3731f7e08757 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -120,8 +120,21 @@ * protection key is treated like _PAGE_RW, for * instance, and is *not* included in this mask since * pte_modify() does modify it. + * + * They include the physical address and the memory encryption keyID. + * The paddr and the keyID never occupy the same bits at the same time. + * But, a given bit might be used for the keyID on one system and used for + * the physical address on another. As an optimization, we manage them in + * one unit here since their combination always occupies the same hardware + * bits. PTE_PFN_MASK_MAX stores combined mask. + * + * Cast PAGE_MASK to a signed type so that it is sign-extended if + * virtual addresses are 32-bits but physical addresses are larger + * (ie, 32-bit PAE). */ -#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ +#define PTE_PFN_MASK_MAX \ + (((signed long)PAGE_MASK) & ((1ULL << __PHYSICAL_MASK_SHIFT) - 1)) +#define _PAGE_CHG_MASK (PTE_PFN_MASK_MAX | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ _PAGE_SOFT_DIRTY) #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way we don't need to do anything special to setup encrypted page table entries and don't need to reserve space for KeyID in a VMA. This patch changes _PAGE_CHG_MASK to include KeyID bits. Otherwise they are going to be stripped from vm_page_prot on the first pgprot_modify(). Define PTE_PFN_MASK_MAX similar to PTE_PFN_MASK but based on __PHYSICAL_MASK_SHIFT. This way we include whole range of bits architecturally available for PFN without referencing physical_mask and mktme_keyid_mask variables. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> --- arch/x86/include/asm/pgtable_types.h | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)