All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	William Cohen <wcohen@redhat.com>,
	stable <stable@vger.kernel.org>,
	Laura Abbott <labbott@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	lttng <lttng@reliableembeddedsystems.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: BUG: optimized kprobes illegal instructions in v4.19 stable kernels
Date: Thu, 21 Feb 2019 15:02:57 -0500 (EST)	[thread overview]
Message-ID: <1829800918.4014.1550779377803.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <843587666.153.1550501735273.JavaMail.zimbra@efficios.com>

Hi Arnd, Russell, Linus,

Can we ensure the arm32 kprobes fix I submitted gets upstream before 5.0 final ?
It takes care of an illegal instruction issue with optimized kprobes on arm32.

Here is the current state of default kprobes configuration on arm32:
using them will trigger illegal instruction OOPS on v5.0-rc7, 4.19.24,
v4.14.102.

My fix is in "accepted" state in the arm patch tracking system:

https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8834/1

Should I send it directly to Linus as well ?

Thanks,

Mathieu

----- On Feb 18, 2019, at 9:55 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> ----- On Feb 18, 2019, at 7:26 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org
> wrote:
> 
>> On Wed, Feb 06, 2019 at 01:41:15PM +0900, Masami Hiramatsu wrote:
>>> On Tue, 5 Feb 2019 15:06:10 +0000
>>> Kees Cook <keescook@chromium.org> wrote:
>>> 
>>> > On Mon, Feb 4, 2019 at 7:15 PM Mathieu Desnoyers
>>> > <mathieu.desnoyers@efficios.com> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I notice this commit as a possible culprit of the illegal instructions my lttng
>>> > > users are noticing on arm32 when using kprobes on a v4.19.13 Linux kernel
>>> > > in a Yocto environment [1]. They were able to reproduce the issue with perf
>>> > > as well.
>>> > >
>>> > > commit e46daee53bb50bde38805f1823a182979724c229
>>> > > Author: Kees Cook <keescook@chromium.org>
>>> > > Date:   Tue Oct 30 22:12:56 2018 +0100
>>> > >
>>> > >     ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE
>>> > >
>>> > > I *think* the intent there was to do
>>> > >
>>> > > -       memcpy(code, &optprobe_template_entry,
>>> > > +       memcpy(code, (unsigned long *)&optprobe_template_entry,
>>> > >
>>> > > But if you look at the commit, the "&" seems to have been stripped away,
>>> > > which happens to change the behavior significantly.
>>> > 
>>> > Yeah, this was a typo on my part. :(
>>> 
>>> Ah, I thought it had been fixed as same as x86.
>>> On x86, all optprobe_template_* are defined as kprobe_opcode_t [],
>>> but on arm, it still be kprobe_opcode_t.
>>> 
>>> Hmm, but I think we should use kprobe_opcode_t [] or char[] as asm/sections.h
>>> does.
>>> OK, I'll prepare for the change.
>> 
>> Did this ever get fixed in Linus's tree?  If so, what is the git commit
>> id, I can't seem to find anything...
> 
> It seems to still be in the arm patch tracking system:
> 
> https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8834/1
> 
> If I understand its status correctly, it is applied to the arm tree, but
> perhaps it has not been pulled by Linus yet ? The code is still broken
> in Linus' master.
> 
> It would be important to get this arm kprobes fix upstream before 5.0
> final.
> 
> Thanks,
> 
> Mathieu
> 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2019-02-21 20:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 19:15 BUG: optimized kprobes illegal instructions in v4.19 stable kernels Mathieu Desnoyers
2019-02-05 15:06 ` Kees Cook
2019-02-06  4:41   ` Masami Hiramatsu
2019-02-18 12:26     ` Greg KH
2019-02-18 14:11       ` Masami Hiramatsu
2019-02-18 14:55       ` Mathieu Desnoyers
2019-02-21 20:02         ` Mathieu Desnoyers [this message]
2019-02-22  0:10           ` Russell King - ARM Linux admin
2019-02-22  0:17             ` Mathieu Desnoyers
2019-02-22  6:25               ` Greg Kroah-Hartman
2019-02-22  8:29                 ` Greg Kroah-Hartman
2019-02-22 20:18                   ` Mathieu Desnoyers
2019-02-06 11:48 ` David Laight

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=1829800918.4014.1550779377803.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lttng@reliableembeddedsystems.com \
    --cc=mhiramat@kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=wcohen@redhat.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.