All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/8] arm: fixmap: implement __set_fixmap()
Date: Wed, 10 Sep 2014 18:51:26 +0100	[thread overview]
Message-ID: <20140910175126.GJ1710@arm.com> (raw)
In-Reply-To: <CAGXu5jJoW-B7WwuFUhbN4e1aL-HVxa9x4da9hB9DcCGEXVLgzw@mail.gmail.com>

Hi Kees,

On Tue, Sep 09, 2014 at 03:33:11PM +0100, Kees Cook wrote:
> On Tue, Sep 9, 2014 at 5:38 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Sep 08, 2014 at 11:40:43PM +0100, Kees Cook wrote:
> >> Ah, so it was, yes! Will, which version of this logic would you prefer?
> >
> > I still don't think we're solving the general problem here -- we're actually
> > just making the ftrace case work. It is perfectly possible for another CPU
> > to undergo a TLB miss and refill whilst the page table is being modified by
> > the CPU with preemption disabled. In this case, a local tlb flush won't
> > invalidate that entry on the other core, and we have no way of knowing when
> > the original permissions are actually observed across the system.
> 
> The fixmap is used by anything doing patching _except_ ftrace,
> actually. It's used by jump labels, kprobes, and kgdb. This code is
> the general case. Access to set_fixmap is done via the kernel patching
> interface: patch_text().
> 
> Right now, the patch_text interface checks cache_ops_need_broadcast(),
> and conditionally runs under stop_machine(). We could make this
> unconditional, and we'll avoid any problem with TLB misses on another
> CPU.

Yes, it we always use stop_machine, that solves the TLB broadcast problem
and we could do that if CONFIG_ARM_ERRATA_798181 is set.

> > So I think we need to figure out a way to invalidate the TLB properly. What
> > do architectures that use IPIs for TLB broadcasting do (x86, some powerpc,
> > mips, ...)? They must have exactly the same problem.
> 
> I don't think this should be done at the set_fixmap level, as it is
> more a primitive. I think making sure patch_text() always works would
> be best. What do you think of using an unconditional stop_machine()
> instead?

Why not move the TLB invalidation into patch_text, then we can do
stop_machine if IS_ENABLED(CONFIG_ARM_ERRATA_798181) ||
tlb_ops_need_broadcast()?

Then that just leaves ftrace.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Kees Cook <keescook@chromium.org>
Cc: Rabin Vincent <rabin@rab.in>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Laura Abbott <lauraa@codeaurora.org>,
	Rob Herring <robh@kernel.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	"msalter@redhat.com" <msalter@redhat.com>,
	Liu hua <sdu.liu@huawei.com>,
	Nikolay Borisov <Nikolay.Borisov@arm.com>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Doug Anderson <dianders@google.com>,
	Jason Wessel <jason.wessel@windriver.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/8] arm: fixmap: implement __set_fixmap()
Date: Wed, 10 Sep 2014 18:51:26 +0100	[thread overview]
Message-ID: <20140910175126.GJ1710@arm.com> (raw)
In-Reply-To: <CAGXu5jJoW-B7WwuFUhbN4e1aL-HVxa9x4da9hB9DcCGEXVLgzw@mail.gmail.com>

Hi Kees,

On Tue, Sep 09, 2014 at 03:33:11PM +0100, Kees Cook wrote:
> On Tue, Sep 9, 2014 at 5:38 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Sep 08, 2014 at 11:40:43PM +0100, Kees Cook wrote:
> >> Ah, so it was, yes! Will, which version of this logic would you prefer?
> >
> > I still don't think we're solving the general problem here -- we're actually
> > just making the ftrace case work. It is perfectly possible for another CPU
> > to undergo a TLB miss and refill whilst the page table is being modified by
> > the CPU with preemption disabled. In this case, a local tlb flush won't
> > invalidate that entry on the other core, and we have no way of knowing when
> > the original permissions are actually observed across the system.
> 
> The fixmap is used by anything doing patching _except_ ftrace,
> actually. It's used by jump labels, kprobes, and kgdb. This code is
> the general case. Access to set_fixmap is done via the kernel patching
> interface: patch_text().
> 
> Right now, the patch_text interface checks cache_ops_need_broadcast(),
> and conditionally runs under stop_machine(). We could make this
> unconditional, and we'll avoid any problem with TLB misses on another
> CPU.

Yes, it we always use stop_machine, that solves the TLB broadcast problem
and we could do that if CONFIG_ARM_ERRATA_798181 is set.

> > So I think we need to figure out a way to invalidate the TLB properly. What
> > do architectures that use IPIs for TLB broadcasting do (x86, some powerpc,
> > mips, ...)? They must have exactly the same problem.
> 
> I don't think this should be done at the set_fixmap level, as it is
> more a primitive. I think making sure patch_text() always works would
> be best. What do you think of using an unconditional stop_machine()
> instead?

Why not move the TLB invalidation into patch_text, then we can do
stop_machine if IS_ENABLED(CONFIG_ARM_ERRATA_798181) ||
tlb_ops_need_broadcast()?

Then that just leaves ftrace.

Will

  reply	other threads:[~2014-09-10 17:51 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 21:57 [PATCH v5 0/8] arm: support CONFIG_RODATA Kees Cook
2014-09-03 21:57 ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 1/8] arm: use generic fixmap.h Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 2/8] ARM: expand fixmap region to 3MB Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 3/8] arm: fixmap: implement __set_fixmap() Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-04 17:03   ` Will Deacon
2014-09-04 17:03     ` Will Deacon
2014-09-04 17:23     ` Kees Cook
2014-09-04 17:23       ` Kees Cook
2014-09-04 17:27       ` Will Deacon
2014-09-04 17:27         ` Will Deacon
2014-09-05 19:41         ` Kees Cook
2014-09-05 19:41           ` Kees Cook
2014-09-08 10:39           ` Will Deacon
2014-09-08 10:39             ` Will Deacon
2014-09-08 18:38             ` Kees Cook
2014-09-08 18:38               ` Kees Cook
2014-09-08 19:16         ` Kees Cook
2014-09-08 19:16           ` Kees Cook
2014-09-08 21:55           ` Rabin Vincent
2014-09-08 21:55             ` Rabin Vincent
2014-09-08 22:40             ` Kees Cook
2014-09-08 22:40               ` Kees Cook
2014-09-09 12:38               ` Will Deacon
2014-09-09 12:38                 ` Will Deacon
2014-09-09 14:33                 ` Kees Cook
2014-09-09 14:33                   ` Kees Cook
2014-09-10 17:51                   ` Will Deacon [this message]
2014-09-10 17:51                     ` Will Deacon
2014-09-11 15:27                     ` Kees Cook
2014-09-11 15:27                       ` Kees Cook
2014-09-11 16:05                       ` Kees Cook
2014-09-11 16:05                         ` Kees Cook
2014-09-11 16:16                         ` Will Deacon
2014-09-11 16:16                           ` Will Deacon
2014-09-11 16:27                           ` Kees Cook
2014-09-11 16:27                             ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 4/8] arm: use fixmap for text patching when text is RO Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 5/8] ARM: kexec: Make .text R/W in machine_kexec Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 6/8] arm: kgdb: Handle read-only text / modules Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 7/8] ARM: mm: allow non-text sections to be non-executable Kees Cook
2014-09-03 21:57   ` Kees Cook
2014-09-03 21:57 ` [PATCH v5 8/8] ARM: mm: allow text and rodata sections to be read-only Kees Cook
2014-09-03 21:57   ` Kees Cook

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=20140910175126.GJ1710@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.