All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rabin Vincent <rabin@rab.in>, Rob Herring <robh@kernel.org>,
	Laura Abbott <lauraa@codeaurora.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.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>,
	Tomasz Figa <t.figa@samsung.com>,
	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>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v4 4/8] arm: use fixmap for text patching when text is RO
Date: Wed, 3 Sep 2014 14:43:58 -0700	[thread overview]
Message-ID: <CAGXu5jJ890ruLO8Nit2exMSWigSM71kfZOkLoF0DcY1viFiX_A@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jLxqyfJtg8rR9nzOrSBSsRC6y34rG6mZ8bb=AoxbSHkWQ@mail.gmail.com>

On Wed, Aug 20, 2014 at 5:28 AM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Aug 19, 2014 at 7:29 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Hello,
>>
>> On Wed, Aug 13, 2014 at 06:06:29PM +0100, Kees Cook wrote:
>>> From: Rabin Vincent <rabin@rab.in>
>>>
>>> Use fixmaps for text patching when the kernel text is read-only,
>>> inspired by x86.  This makes jump labels and kprobes work with the
>>> currently available CONFIG_DEBUG_SET_MODULE_RONX and the upcoming
>>> CONFIG_DEBUG_RODATA options.
>>>
>>> Signed-off-by: Rabin Vincent <rabin@rab.in>
>>> [kees: fixed up for merge with "arm: use generic fixmap.h"]
>>> [kees: added parse acquire/release annotations to pass C=1 builds]
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>
>> [...]
>>
>>> diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
>>> index 07314af47733..a1dce690446a 100644
>>> --- a/arch/arm/kernel/patch.c
>>> +++ b/arch/arm/kernel/patch.c
>>> @@ -1,8 +1,11 @@
>>>  #include <linux/kernel.h>
>>> +#include <linux/spinlock.h>
>>>  #include <linux/kprobes.h>
>>> +#include <linux/mm.h>
>>>  #include <linux/stop_machine.h>
>>>
>>>  #include <asm/cacheflush.h>
>>> +#include <asm/fixmap.h>
>>>  #include <asm/smp_plat.h>
>>>  #include <asm/opcodes.h>
>>>
>>> @@ -13,21 +16,77 @@ struct patch {
>>>       unsigned int insn;
>>>  };
>>>
>>> -void __kprobes __patch_text(void *addr, unsigned int insn)
>>> +static DEFINE_SPINLOCK(patch_lock);
>>> +
>>> +static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
>>> +     __acquires(&patch_lock)
>>> +{
>>> +     unsigned int uintaddr = (uintptr_t) addr;
>>> +     bool module = !core_kernel_text(uintaddr);
>>> +     struct page *page;
>>> +
>>> +     if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
>>> +             page = vmalloc_to_page(addr);
>>> +     else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
>>> +             page = virt_to_page(addr);
>>> +     else
>>> +             return addr;
>>> +
>>> +     if (flags)
>>> +             spin_lock_irqsave(&patch_lock, *flags);
>>> +     else
>>> +             __acquire(&patch_lock);
>>
>> I don't understand the locking here. Why is it conditional, why do we need
>> to disable interrupts, and are you just racing against yourself?
>
> AIUI, the locking is here to avoid multiple users of the text poking
> fixmaps. It's conditional because there are two fixmaps
> (FIX_TEXT_POKE0 and FIX_TEXT_POKE1). Locking happens around 0 so
> locking around 1 is not needed since it is only ever used when 0 is in
> use. (__patch_text_real locks patch_lock before setting 0 when it uses
> remapping, and if it also needs 1, it doesn't have to lock since the
> lock is already held.)
>
>>> +     set_fixmap(fixmap, page_to_phys(page));
>>
>> set_fixmap does TLB invalidation, right? I think that means it can block on
>> 11MPCore and A15 w/ the TLBI erratum, so it's not safe to call this with
>> interrupts disabled anyway.
>
> Oh right. Hrm.
>
> In an earlier version of this series set_fixmap did not perform TLB
> invalidation. I wonder if this is not needed at all? (Wouldn't that be
> nice...)

As suspected, my tests fail spectacularly without the TLB flush.
Adding WARN_ON(!irqs_disabled()) doesn't warn, so I think we're safe
here. Should I leave the WARN_ON in place for clarity, or some other
comments?

-Kees

-- 
Kees Cook
Chrome OS Security

WARNING: multiple messages have this Message-ID (diff)
From: keescook@chromium.org (Kees Cook)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/8] arm: use fixmap for text patching when text is RO
Date: Wed, 3 Sep 2014 14:43:58 -0700	[thread overview]
Message-ID: <CAGXu5jJ890ruLO8Nit2exMSWigSM71kfZOkLoF0DcY1viFiX_A@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jLxqyfJtg8rR9nzOrSBSsRC6y34rG6mZ8bb=AoxbSHkWQ@mail.gmail.com>

On Wed, Aug 20, 2014 at 5:28 AM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Aug 19, 2014 at 7:29 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Hello,
>>
>> On Wed, Aug 13, 2014 at 06:06:29PM +0100, Kees Cook wrote:
>>> From: Rabin Vincent <rabin@rab.in>
>>>
>>> Use fixmaps for text patching when the kernel text is read-only,
>>> inspired by x86.  This makes jump labels and kprobes work with the
>>> currently available CONFIG_DEBUG_SET_MODULE_RONX and the upcoming
>>> CONFIG_DEBUG_RODATA options.
>>>
>>> Signed-off-by: Rabin Vincent <rabin@rab.in>
>>> [kees: fixed up for merge with "arm: use generic fixmap.h"]
>>> [kees: added parse acquire/release annotations to pass C=1 builds]
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>
>> [...]
>>
>>> diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
>>> index 07314af47733..a1dce690446a 100644
>>> --- a/arch/arm/kernel/patch.c
>>> +++ b/arch/arm/kernel/patch.c
>>> @@ -1,8 +1,11 @@
>>>  #include <linux/kernel.h>
>>> +#include <linux/spinlock.h>
>>>  #include <linux/kprobes.h>
>>> +#include <linux/mm.h>
>>>  #include <linux/stop_machine.h>
>>>
>>>  #include <asm/cacheflush.h>
>>> +#include <asm/fixmap.h>
>>>  #include <asm/smp_plat.h>
>>>  #include <asm/opcodes.h>
>>>
>>> @@ -13,21 +16,77 @@ struct patch {
>>>       unsigned int insn;
>>>  };
>>>
>>> -void __kprobes __patch_text(void *addr, unsigned int insn)
>>> +static DEFINE_SPINLOCK(patch_lock);
>>> +
>>> +static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
>>> +     __acquires(&patch_lock)
>>> +{
>>> +     unsigned int uintaddr = (uintptr_t) addr;
>>> +     bool module = !core_kernel_text(uintaddr);
>>> +     struct page *page;
>>> +
>>> +     if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
>>> +             page = vmalloc_to_page(addr);
>>> +     else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
>>> +             page = virt_to_page(addr);
>>> +     else
>>> +             return addr;
>>> +
>>> +     if (flags)
>>> +             spin_lock_irqsave(&patch_lock, *flags);
>>> +     else
>>> +             __acquire(&patch_lock);
>>
>> I don't understand the locking here. Why is it conditional, why do we need
>> to disable interrupts, and are you just racing against yourself?
>
> AIUI, the locking is here to avoid multiple users of the text poking
> fixmaps. It's conditional because there are two fixmaps
> (FIX_TEXT_POKE0 and FIX_TEXT_POKE1). Locking happens around 0 so
> locking around 1 is not needed since it is only ever used when 0 is in
> use. (__patch_text_real locks patch_lock before setting 0 when it uses
> remapping, and if it also needs 1, it doesn't have to lock since the
> lock is already held.)
>
>>> +     set_fixmap(fixmap, page_to_phys(page));
>>
>> set_fixmap does TLB invalidation, right? I think that means it can block on
>> 11MPCore and A15 w/ the TLBI erratum, so it's not safe to call this with
>> interrupts disabled anyway.
>
> Oh right. Hrm.
>
> In an earlier version of this series set_fixmap did not perform TLB
> invalidation. I wonder if this is not needed at all? (Wouldn't that be
> nice...)

As suspected, my tests fail spectacularly without the TLB flush.
Adding WARN_ON(!irqs_disabled()) doesn't warn, so I think we're safe
here. Should I leave the WARN_ON in place for clarity, or some other
comments?

-Kees

-- 
Kees Cook
Chrome OS Security

  reply	other threads:[~2014-09-03 21:44 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 17:06 [PATCH v4 0/8] arm: support CONFIG_RODATA Kees Cook
2014-08-13 17:06 ` Kees Cook
2014-08-13 17:06 ` [PATCH v4 1/8] arm: use generic fixmap.h Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-13 17:06 ` [PATCH v4 2/8] ARM: expand fixmap region to 3MB Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-19 12:26   ` Will Deacon
2014-08-19 12:26     ` Will Deacon
2014-08-20 12:16     ` Kees Cook
2014-08-20 12:16       ` Kees Cook
2014-08-26 14:37       ` Will Deacon
2014-08-26 14:37         ` Will Deacon
2014-08-13 17:06 ` [PATCH v4 3/8] arm: fixmap: implement __set_fixmap() Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-13 17:06 ` [PATCH v4 4/8] arm: use fixmap for text patching when text is RO Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-19 12:29   ` Will Deacon
2014-08-19 12:29     ` Will Deacon
2014-08-20 12:28     ` Kees Cook
2014-08-20 12:28       ` Kees Cook
2014-09-03 21:43       ` Kees Cook [this message]
2014-09-03 21:43         ` Kees Cook
2014-09-04  9:27         ` Will Deacon
2014-09-04  9:27           ` Will Deacon
2014-09-04 14:00           ` Kees Cook
2014-09-04 14:00             ` Kees Cook
2014-09-04 14:06             ` Will Deacon
2014-09-04 14:06               ` Will Deacon
2014-08-13 17:06 ` [PATCH v4 5/8] ARM: kexec: Make .text R/W in machine_kexec Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-13 17:06 ` [PATCH v4 6/8] arm: kgdb: Handle read-only text / modules Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-13 17:06 ` [PATCH v4 7/8] ARM: mm: allow non-text sections to be non-executable Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-19 12:33   ` Will Deacon
2014-08-19 12:33     ` Will Deacon
2014-08-20 12:37     ` Kees Cook
2014-08-20 12:37       ` Kees Cook
2014-08-26 14:43       ` Will Deacon
2014-08-26 14:43         ` Will Deacon
2014-08-29 16:04         ` Kees Cook
2014-08-29 16:04           ` Kees Cook
2014-08-31 14:59           ` Rabin Vincent
2014-08-31 14:59             ` Rabin Vincent
2014-08-13 17:06 ` [PATCH v4 8/8] ARM: mm: allow text and rodata sections to be read-only Kees Cook
2014-08-13 17:06   ` Kees Cook
2014-08-19 12:36   ` Will Deacon
2014-08-19 12:36     ` Will Deacon
2014-08-20 12:52     ` Kees Cook
2014-08-20 12:52       ` Kees Cook
2014-08-13 17:38 ` [PATCH v4 0/8] arm: support CONFIG_RODATA Nicolas Pitre
2014-08-13 17:38   ` Nicolas Pitre

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=CAGXu5jJ890ruLO8Nit2exMSWigSM71kfZOkLoF0DcY1viFiX_A@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=Catalin.Marinas@arm.com \
    --cc=Nikolay.Borisov@arm.com \
    --cc=dianders@google.com \
    --cc=jason.wessel@windriver.com \
    --cc=lauraa@codeaurora.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=msalter@redhat.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=rabin@rab.in \
    --cc=robh@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sdu.liu@huawei.com \
    --cc=t.figa@samsung.com \
    --cc=will.deacon@arm.com \
    /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.