[LSF/MM TOPIC] Impact on core mm from new hardware features

[LSF/MM TOPIC] Impact on core mm from new hardware features

[Dave Hansen]

I'd like to have a session about new hardware features that may will
have an impact on core memory management.  This session would have two
goals: one to ensure that the OS-agnostic MM crowd understands what the
architectures are going to be throwing their way.  Second, that the
different arch-specific folks can look for commonalities which could
enable shared infrastructure.

There should be enough x86 folks around, but I'd love to hear from the
ARM and powerpc people as well.

Here are a few mostly Intel-specific things I'd like to discuss.
However, all of these either have analogs on other architectures or are
implemented by other x86 vendors.

 * Shadow Stacks - requires new Copy-on-Read memory type.  Creates
   application mappings which are effectively PROT_NONE, but which are
   implicitly accessible by the hardware.
 * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore
   (TBI).  Repurpose some virtual address bits to store metadata.  Intel
   implementation can sacrifice user address space.  Offloads some of
   the work the compiler does in ASAN implementations.
 * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys)
   to kernel mappings.
 * TDX - VMs that don't trust the hypervisor.  Requires unmapping guest
   memory from userspace and possibly the host kernel.

I would also expect there to be a few more things that will become
available to discuss between now and the conference.

Re: [LSF/MM TOPIC] Impact on core mm from new hardware features

[Matthew Wilcox]

On Tue, Jun 22, 2021 at 07:55:48AM -0700, Dave Hansen wrote:
> There should be enough x86 folks around, but I'd love to hear from the
> ARM and powerpc people as well.

Possibly also s390.  eg f28d43636d6f seems very similar to one of the
things Intel wants.

> Here are a few mostly Intel-specific things I'd like to discuss.
> However, all of these either have analogs on other architectures or are
> implemented by other x86 vendors.
> 
>  * Shadow Stacks - requires new Copy-on-Read memory type.  Creates
>    application mappings which are effectively PROT_NONE, but which are
>    implicitly accessible by the hardware.
>  * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore
>    (TBI).  Repurpose some virtual address bits to store metadata.  Intel
>    implementation can sacrifice user address space.  Offloads some of
>    the work the compiler does in ASAN implementations.
>  * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys)
>    to kernel mappings.
>  * TDX - VMs that don't trust the hypervisor.  Requires unmapping guest
>    memory from userspace and possibly the host kernel.

Re: [Lsf-pc] [LSF/MM TOPIC] Impact on core mm from new hardware features

[Dan Williams]

On Tue, Jun 22, 2021 at 7:56 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> I'd like to have a session about new hardware features that may will
> have an impact on core memory management.  This session would have two
> goals: one to ensure that the OS-agnostic MM crowd understands what the
> architectures are going to be throwing their way.  Second, that the
> different arch-specific folks can look for commonalities which could
> enable shared infrastructure.
>
> There should be enough x86 folks around, but I'd love to hear from the
> ARM and powerpc people as well.
>
> Here are a few mostly Intel-specific things I'd like to discuss.
> However, all of these either have analogs on other architectures or are
> implemented by other x86 vendors.
>
>  * Shadow Stacks - requires new Copy-on-Read memory type.  Creates
>    application mappings which are effectively PROT_NONE, but which are
>    implicitly accessible by the hardware.
>  * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore
>    (TBI).  Repurpose some virtual address bits to store metadata.  Intel
>    implementation can sacrifice user address space.  Offloads some of
>    the work the compiler does in ASAN implementations.
>  * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys)
>    to kernel mappings.
>  * TDX - VMs that don't trust the hypervisor.  Requires unmapping guest
>    memory from userspace and possibly the host kernel.

A tangential conversation that may not need air time in person, but is
worth mentioning in this context is what to do when CPU memory feature
X only works on the DDR attached memory and not the CXL attached
memory?

The unsatisfying position we have currently arrived at is "trust
platform firmware". Trust it to either disable CXL, or disable memory
feature X if CXL is enabled [1].

[1]: https://lore.kernel.org/r/CAPcyv4jztOGShTF+pVSMAtGeK4giHvC3mGNa5bC0pXz=2ZcrJw@mail.gmail.com

Re: [LSF/MM TOPIC] Impact on core mm from new hardware features

[Michael Ellerman]

Dave Hansen <dave.hansen@intel.com> writes:
> I'd like to have a session about new hardware features that may will
> have an impact on core memory management.  This session would have two
> goals: one to ensure that the OS-agnostic MM crowd understands what the
> architectures are going to be throwing their way.  Second, that the
> different arch-specific folks can look for commonalities which could
> enable shared infrastructure.
>
> There should be enough x86 folks around, but I'd love to hear from the
> ARM and powerpc people as well.

Cc += Aneesh and Nick

I can't think of anything publicly announced for Power that will have a
big impact on core mm, but Nick & Aneesh might have ideas.

cheers

> Here are a few mostly Intel-specific things I'd like to discuss.
> However, all of these either have analogs on other architectures or are
> implemented by other x86 vendors.
>
>  * Shadow Stacks - requires new Copy-on-Read memory type.  Creates
>    application mappings which are effectively PROT_NONE, but which are
>    implicitly accessible by the hardware.
>  * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore
>    (TBI).  Repurpose some virtual address bits to store metadata.  Intel
>    implementation can sacrifice user address space.  Offloads some of
>    the work the compiler does in ASAN implementations.
>  * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys)
>    to kernel mappings.
>  * TDX - VMs that don't trust the hypervisor.  Requires unmapping guest
>    memory from userspace and possibly the host kernel.

Re: [LSF/MM TOPIC] Impact on core mm from new hardware features

[Ira Weiny]

On Fri, Jun 25, 2021 at 09:38:18PM +1000, Michael Ellerman wrote:
> Dave Hansen <dave.hansen@intel.com> writes:
> > I'd like to have a session about new hardware features that may will
> > have an impact on core memory management.  This session would have two
> > goals: one to ensure that the OS-agnostic MM crowd understands what the
> > architectures are going to be throwing their way.  Second, that the
> > different arch-specific folks can look for commonalities which could
> > enable shared infrastructure.

I'm interested in this subject.

> >
> > There should be enough x86 folks around, but I'd love to hear from the
> > ARM and powerpc people as well.
> 
> Cc += Aneesh and Nick
> 
> I can't think of anything publicly announced for Power that will have a
> big impact on core mm, but Nick & Aneesh might have ideas.
> 
> cheers
> 
> > Here are a few mostly Intel-specific things I'd like to discuss.
> > However, all of these either have analogs on other architectures or are
> > implemented by other x86 vendors.
> >
> >  * Shadow Stacks - requires new Copy-on-Read memory type.  Creates
> >    application mappings which are effectively PROT_NONE, but which are
> >    implicitly accessible by the hardware.
> >  * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore
> >    (TBI).  Repurpose some virtual address bits to store metadata.  Intel
> >    implementation can sacrifice user address space.  Offloads some of
> >    the work the compiler does in ASAN implementations.
> >  * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys)
> >    to kernel mappings.

I'd be more than happy to share what I've tried to do to make this support
generic.

Ira

> >  * TDX - VMs that don't trust the hypervisor.  Requires unmapping guest
> >    memory from userspace and possibly the host kernel.
> 
> 
> 
>