| Message ID | 20180626142245.82850-19-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/26/2018 07:22 AM, Kirill A. Shutemov wrote: > Add new config option to enabled/disable Multi-Key Total Memory > Encryption support. > > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID > direct mappings for memory hotplug. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > arch/x86/Kconfig | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index fa5e1ec09247..9a843bd63108 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT > def_bool y > depends on AMD_MEM_ENCRYPT > > +config X86_INTEL_MKTME > + bool "Intel Multi-Key Total Memory Encryption" > + select DYNAMIC_PHYSICAL_MASK > + select PAGE_EXTENSION > + depends on X86_64 && CPU_SUP_INTEL > + ---help--- > + Say yes to enable support for Multi-Key Total Memory Encryption. > + This requires an Intel processor that has support of the feature. > + > + Multikey Total Memory Encryption (MKTME) is a technology that allows > + transparent memory encryption in and upcoming Intel platforms. huh? Maybe drop the "and"? > + > + MKTME is built on top of TME. TME allows encryption of the entirety > + of system memory using a single key. MKTME allows having multiple > + encryption domains, each having own key -- different memory pages can > + be encrypted with different keys. > + > # Common NUMA Features > config NUMA > bool "Numa Memory Allocation and Scheduler Support" > @@ -2199,7 +2216,7 @@ config RANDOMIZE_MEMORY > > config MEMORY_PHYSICAL_PADDING > hex "Physical memory mapping padding" if EXPERT > - depends on RANDOMIZE_MEMORY > + depends on RANDOMIZE_MEMORY || X86_INTEL_MKTME > default "0xa" if MEMORY_HOTPLUG > default "0x0" > range 0x1 0x40 if MEMORY_HOTPLUG >
On Tue, Jun 26, 2018 at 05:30:12PM +0000, Randy Dunlap wrote: > On 06/26/2018 07:22 AM, Kirill A. Shutemov wrote: > > Add new config option to enabled/disable Multi-Key Total Memory > > Encryption support. > > > > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID > > direct mappings for memory hotplug. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > --- > > arch/x86/Kconfig | 19 ++++++++++++++++++- > > 1 file changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index fa5e1ec09247..9a843bd63108 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT > > def_bool y > > depends on AMD_MEM_ENCRYPT > > > > +config X86_INTEL_MKTME > > + bool "Intel Multi-Key Total Memory Encryption" > > + select DYNAMIC_PHYSICAL_MASK > > + select PAGE_EXTENSION > > + depends on X86_64 && CPU_SUP_INTEL > > + ---help--- > > + Say yes to enable support for Multi-Key Total Memory Encryption. > > + This requires an Intel processor that has support of the feature. > > + > > + Multikey Total Memory Encryption (MKTME) is a technology that allows > > + transparent memory encryption in and upcoming Intel platforms. > > huh? Maybe drop the "and"? Ugh.. It has to be "an".
On 06/27/2018 02:57 PM, Kirill A. Shutemov wrote: > On Tue, Jun 26, 2018 at 05:30:12PM +0000, Randy Dunlap wrote: >> On 06/26/2018 07:22 AM, Kirill A. Shutemov wrote: >>> Add new config option to enabled/disable Multi-Key Total Memory >>> Encryption support. >>> >>> MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID >>> direct mappings for memory hotplug. >>> >>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> >>> --- >>> arch/x86/Kconfig | 19 ++++++++++++++++++- >>> 1 file changed, 18 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index fa5e1ec09247..9a843bd63108 100644 >>> --- a/arch/x86/Kconfig >>> +++ b/arch/x86/Kconfig >>> @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT >>> def_bool y >>> depends on AMD_MEM_ENCRYPT >>> >>> +config X86_INTEL_MKTME >>> + bool "Intel Multi-Key Total Memory Encryption" >>> + select DYNAMIC_PHYSICAL_MASK >>> + select PAGE_EXTENSION >>> + depends on X86_64 && CPU_SUP_INTEL >>> + ---help--- >>> + Say yes to enable support for Multi-Key Total Memory Encryption. >>> + This requires an Intel processor that has support of the feature. >>> + >>> + Multikey Total Memory Encryption (MKTME) is a technology that allows >>> + transparent memory encryption in and upcoming Intel platforms. >> >> huh? Maybe drop the "and"? > > Ugh.. It has to be "an". an ... platform. or in upcoming Intel platforms.
On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote: > Add new config option to enabled/disable Multi-Key Total Memory > Encryption support. > > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID > direct mappings for memory hotplug. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > arch/x86/Kconfig | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index fa5e1ec09247..9a843bd63108 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT > def_bool y > depends on AMD_MEM_ENCRYPT > > +config X86_INTEL_MKTME Rip out the X86? > + bool "Intel Multi-Key Total Memory Encryption" > + select DYNAMIC_PHYSICAL_MASK > + select PAGE_EXTENSION And maybe select 5-page? > + depends on X86_64 && CPU_SUP_INTEL > + ---help--- > + Say yes to enable support for Multi-Key Total Memory Encryption. > + This requires an Intel processor that has support of the feature. > + > + Multikey Total Memory Encryption (MKTME) is a technology that allows > + transparent memory encryption in and upcoming Intel platforms. How about saying which CPUs? Or just dropping this? > + > + MKTME is built on top of TME. TME allows encryption of the entirety > + of system memory using a single key. MKTME allows having multiple > + encryption domains, each having own key -- different memory pages can > + be encrypted with different keys. > + > # Common NUMA Features > config NUMA > bool "Numa Memory Allocation and Scheduler Support" > @@ -2199,7 +2216,7 @@ config RANDOMIZE_MEMORY > > config MEMORY_PHYSICAL_PADDING > hex "Physical memory mapping padding" if EXPERT > - depends on RANDOMIZE_MEMORY > + depends on RANDOMIZE_MEMORY || X86_INTEL_MKTME > default "0xa" if MEMORY_HOTPLUG > default "0x0" > range 0x1 0x40 if MEMORY_HOTPLUG > -- > 2.18.0 >
On 07/09/2018 11:36 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote: > Rip out the X86? >> + bool "Intel Multi-Key Total Memory Encryption" >> + select DYNAMIC_PHYSICAL_MASK >> + select PAGE_EXTENSION > > And maybe select 5-page? Why? It's not a strict dependency. You *can* build a 4-level kernel and run it on smaller systems. >> + depends on X86_64 && CPU_SUP_INTEL >> + ---help--- >> + Say yes to enable support for Multi-Key Total Memory Encryption. >> + This requires an Intel processor that has support of the feature. >> + >> + Multikey Total Memory Encryption (MKTME) is a technology that allows >> + transparent memory encryption in and upcoming Intel platforms. > > How about saying which CPUs? Or just dropping this? We don't have any information about specifically which processors with have this feature to share. But, this config text does tell someone that they can't use this feature on today's platforms. We _did_ say this for previous features (protection keys stands out where we said it was for "Skylake Servers" IIRC), but we are not yet able to do the same for this feature.
On Mon, Jul 09, 2018 at 11:44:33AM -0700, Dave Hansen wrote: > On 07/09/2018 11:36 AM, Konrad Rzeszutek Wilk wrote: > > On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote: > > Rip out the X86? > >> + bool "Intel Multi-Key Total Memory Encryption" > >> + select DYNAMIC_PHYSICAL_MASK > >> + select PAGE_EXTENSION > > > > And maybe select 5-page? > > Why? It's not a strict dependency. You *can* build a 4-level kernel > and run it on smaller systems. Sure, but in one of his commits he mentions that we may run in overlapping physical memory if we use 4-level paging. Hence why not just move to 5-level paging and simplify this. > > >> + depends on X86_64 && CPU_SUP_INTEL > >> + ---help--- > >> + Say yes to enable support for Multi-Key Total Memory Encryption. > >> + This requires an Intel processor that has support of the feature. > >> + > >> + Multikey Total Memory Encryption (MKTME) is a technology that allows > >> + transparent memory encryption in and upcoming Intel platforms. > > > > How about saying which CPUs? Or just dropping this? > > We don't have any information about specifically which processors with > have this feature to share. But, this config text does tell someone > that they can't use this feature on today's platforms. > > We _did_ say this for previous features (protection keys stands out > where we said it was for "Skylake Servers" IIRC), but we are not yet > able to do the same for this feature.
On 07/09/2018 11:52 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Jul 09, 2018 at 11:44:33AM -0700, Dave Hansen wrote: >> On 07/09/2018 11:36 AM, Konrad Rzeszutek Wilk wrote: >>> On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote: >>> Rip out the X86? >>>> + bool "Intel Multi-Key Total Memory Encryption" >>>> + select DYNAMIC_PHYSICAL_MASK >>>> + select PAGE_EXTENSION >>> >>> And maybe select 5-page? >> >> Why? It's not a strict dependency. You *can* build a 4-level kernel >> and run it on smaller systems. > > Sure, but in one of his commits he mentions that we may run in overlapping > physical memory if we use 4-level paging. Hence why not just move to 5-level > paging and simplify this. I'm not sure it _actually_ simplifies anything. We still need code to handle the cases where we bump into the limits because even 5-level paging systems can hit the *architectural* limits. We just don't think we'll bump into those limits any time soon in practice since they're 512x larger on 5-level systems. But, a future system that needs physical address space or has a bunch more KeyID bits might bump into the limits. It's also _possible_ that a processor could come out that supports MKTME but not 5-level paging, or a hypervisor would expose such a configuration to a guest. We've asked our colleagues very nicely that Intel not make a processor that does this, but it's still possible one shows up.
On Mon, Jul 09, 2018 at 11:59:33AM -0700, Dave Hansen wrote: > On 07/09/2018 11:52 AM, Konrad Rzeszutek Wilk wrote: > > On Mon, Jul 09, 2018 at 11:44:33AM -0700, Dave Hansen wrote: > >> On 07/09/2018 11:36 AM, Konrad Rzeszutek Wilk wrote: > >>> On Tue, Jun 26, 2018 at 05:22:45PM +0300, Kirill A. Shutemov wrote: > >>> Rip out the X86? > >>>> + bool "Intel Multi-Key Total Memory Encryption" > >>>> + select DYNAMIC_PHYSICAL_MASK > >>>> + select PAGE_EXTENSION > >>> > >>> And maybe select 5-page? > >> > >> Why? It's not a strict dependency. You *can* build a 4-level kernel > >> and run it on smaller systems. > > > > Sure, but in one of his commits he mentions that we may run in overlapping > > physical memory if we use 4-level paging. Hence why not just move to 5-level > > paging and simplify this. > > I'm not sure it _actually_ simplifies anything. We still need code to > handle the cases where we bump into the limits because even 5-level > paging systems can hit the *architectural* limits. We just don't think > we'll bump into those limits any time soon in practice since they're > 512x larger on 5-level systems. > > But, a future system that needs physical address space or has a bunch > more KeyID bits might bump into the limits. Yikes. So when will we expand to 128-bit page fields? > > It's also _possible_ that a processor could come out that supports MKTME > but not 5-level paging, or a hypervisor would expose such a > configuration to a guest. We've asked our colleagues very nicely that > Intel not make a processor that does this, but it's still possible one > shows up.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fa5e1ec09247..9a843bd63108 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT def_bool y depends on AMD_MEM_ENCRYPT +config X86_INTEL_MKTME + bool "Intel Multi-Key Total Memory Encryption" + select DYNAMIC_PHYSICAL_MASK + select PAGE_EXTENSION + depends on X86_64 && CPU_SUP_INTEL + ---help--- + Say yes to enable support for Multi-Key Total Memory Encryption. + This requires an Intel processor that has support of the feature. + + Multikey Total Memory Encryption (MKTME) is a technology that allows + transparent memory encryption in and upcoming Intel platforms. + + MKTME is built on top of TME. TME allows encryption of the entirety + of system memory using a single key. MKTME allows having multiple + encryption domains, each having own key -- different memory pages can + be encrypted with different keys. + # Common NUMA Features config NUMA bool "Numa Memory Allocation and Scheduler Support" @@ -2199,7 +2216,7 @@ config RANDOMIZE_MEMORY config MEMORY_PHYSICAL_PADDING hex "Physical memory mapping padding" if EXPERT - depends on RANDOMIZE_MEMORY + depends on RANDOMIZE_MEMORY || X86_INTEL_MKTME default "0xa" if MEMORY_HOTPLUG default "0x0" range 0x1 0x40 if MEMORY_HOTPLUG
Add new config option to enabled/disable Multi-Key Total Memory Encryption support. MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID direct mappings for memory hotplug. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> --- arch/x86/Kconfig | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)