From: Andi Kleen <andi@firstfloor.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>, Jiri Olsa <jolsa@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] fs/proc/kcore.c: Omit kernel text area for hardened usercopy feature
Date: Mon, 5 Sep 2016 09:27:39 -0700 [thread overview]
Message-ID: <20160905162739.GO5871@two.firstfloor.org> (raw)
In-Reply-To: <20160905084722.GA3134@krava>
On Mon, Sep 05, 2016 at 10:47:22AM +0200, Jiri Olsa wrote:
> On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> > On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > > One of the bullets for hardened usercopy feature is:
> > > - object must not overlap with kernel text
> > >
> > > which is what we expose via /proc/kcore. We can hit
> > > this check and crash the system very easily just by
> > > reading the text area in kcore file:
> > >
> > > usercopy: kernel memory exposure attempt detected from ffffffff8179a01f (<kernel text>) (4065 bytes)
> > > kernel BUG at mm/usercopy.c:75!
> > >
> > > Omitting kernel text area from kcore when there's
> > > hardened usercopy feature is enabled.
> >
> > That will completely break PT decoding, which relies on looking
> > at the kernel text in /proc/kcore.
> >
> > Need a different fix here, perhaps some special copy function
> > that is not hardened.
>
> how about something like this
Looks good to me, but you would need the *_nocheck variant for non x86
architectures too of course.
-Andi
next prev parent reply other threads:[~2016-09-05 16:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 12:25 [PATCH] fs/proc/kcore.c: Omit kernel text area for hardened usercopy feature Jiri Olsa
2016-09-02 15:17 ` Andi Kleen
2016-09-02 16:15 ` Jiri Olsa
2016-09-05 8:47 ` Jiri Olsa
2016-09-05 16:27 ` Andi Kleen [this message]
2016-09-06 17:56 ` Kees Cook
2016-09-06 18:34 ` Linus Torvalds
2016-09-06 19:41 ` Andi Kleen
2016-09-06 19:48 ` Linus Torvalds
2016-09-07 17:17 ` Kees Cook
2016-09-07 17:24 ` Linus Torvalds
2016-09-07 7:32 ` Jiri Olsa
2016-09-07 16:38 ` Andi Kleen
2016-09-07 16:58 ` Linus Torvalds
2016-09-07 19:25 ` Jiri Olsa
2016-09-07 21:24 ` Jiri Olsa
2016-09-07 22:52 ` Linus Torvalds
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=20160905162739.GO5871@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=adrian.hunter@intel.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.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.