All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christopher M. Riedl" <cmr@informatik.wtf>
To: "Christophe Leroy" <christophe.leroy@c-s.fr>,
	<linuxppc-dev@lists.ozlabs.org>,
	<kernel-hardening@lists.openwall.com>
Subject: Re: [RFC PATCH v2 1/5] powerpc/mm: Introduce temporary mm
Date: Fri, 01 May 2020 15:46:23 -0500	[thread overview]
Message-ID: <C2FOQZG5ODV4.1I6MYZDG9N0ZE@geist> (raw)
In-Reply-To: <d481ec66-8e14-614f-8e33-d381ce606bc5@c-s.fr>

On Wed Apr 29, 2020 at 7:48 AM, Christophe Leroy wrote:
>
> 
>
> 
> Le 29/04/2020 à 04:05, Christopher M. Riedl a écrit :
> > x86 supports the notion of a temporary mm which restricts access to
> > temporary PTEs to a single CPU. A temporary mm is useful for situations
> > where a CPU needs to perform sensitive operations (such as patching a
> > STRICT_KERNEL_RWX kernel) requiring temporary mappings without exposing
> > said mappings to other CPUs. A side benefit is that other CPU TLBs do
> > not need to be flushed when the temporary mm is torn down.
> > 
> > Mappings in the temporary mm can be set in the userspace portion of the
> > address-space.
> > 
> > Interrupts must be disabled while the temporary mm is in use. HW
> > breakpoints, which may have been set by userspace as watchpoints on
> > addresses now within the temporary mm, are saved and disabled when
> > loading the temporary mm. The HW breakpoints are restored when unloading
> > the temporary mm. All HW breakpoints are indiscriminately disabled while
> > the temporary mm is in use.
>
> 
> Why do we need to use a temporary mm all the time ?
>

Not sure I understand, the temporary mm is only in use for kernel
patching in this series. We could have other uses in the future maybe
where it's beneficial to keep mappings local.

> 
> Doesn't each CPU have its own mm already ? Only the upper address space
> is shared between all mm's but each mm has its own lower address space,
> at least when it is running a user process. Why not just use that mm ?
> As we are mapping then unmapping with interrupts disabled, there is no
> risk at all that the user starts running while the patch page is mapped,
> so I'm not sure why switching to a temporary mm is needed.
>
> 

I suppose that's an option, but then we have to save and restore the
mapping which we temporarily "steal" from userspace. I admit I didn't
consider that as an option when I started this series based on the x86
patches. I think it's cleaner to switch mm, but that's a rather weak
argument. Are you concerned about performance with the temporary mm?

>
> 
> > 
> > Based on x86 implementation:
> > 
> > commit cefa929c034e
> > ("x86/mm: Introduce temporary mm structs")
> > 
> > Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
>
> 
> Christophe
>
> 
>
> 


  reply	other threads:[~2020-05-01 20:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29  2:05 [RFC PATCH v2 0/5] Use per-CPU temporary mappings for patching Christopher M. Riedl
2020-04-29  2:05 ` [RFC PATCH v2 1/5] powerpc/mm: Introduce temporary mm Christopher M. Riedl
2020-04-29  5:39   ` Christophe Leroy
2020-05-01 20:30     ` Christopher M. Riedl
2020-04-29  5:48   ` Christophe Leroy
2020-05-01 20:46     ` Christopher M. Riedl [this message]
2020-04-29  2:05 ` [RFC PATCH v2 2/5] powerpc/lib: Initialize a temporary mm for code patching Christopher M. Riedl
2020-04-29  2:05 ` [RFC PATCH v2 3/5] powerpc/lib: Use " Christopher M. Riedl
2020-04-29  5:52   ` Christophe Leroy
2020-05-01 20:28     ` Christopher M. Riedl
2020-04-29  2:05 ` [RFC PATCH v2 4/5] powerpc/lib: Add LKDTM accessor for patching addr Christopher M. Riedl
2020-04-29  2:05 ` [RFC PATCH v2 5/5] powerpc: Add LKDTM test to hijack a patch mapping Christopher M. Riedl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2FOQZG5ODV4.1I6MYZDG9N0ZE@geist \
    --to=cmr@informatik.wtf \
    --cc=christophe.leroy@c-s.fr \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.