From: Peter Zijlstra <peterz@infradead.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
David Smith <dsmith@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] x86: Verify access_ok() context
Date: Thu, 19 Jan 2017 23:20:08 +0100 [thread overview]
Message-ID: <20170119222008.GI6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20170119212718.GC20931@redhat.com>
On Thu, Jan 19, 2017 at 04:27:18PM -0500, Frank Ch. Eigler wrote:
> Hi, Thomas -
>
> > Well, if you are not in thread context then the check is pointless:
> > __range_not_ok(addr, size, user_addr_max())
> > and:
> > #define user_addr_max() (current->thread.addr_limit.seg)
> >
> > So what guarantees when you are not in context of current, i.e. in thread
> > context, that the addr/size which is checked against the limits of current
> > actually belongs to current?
>
> We're probably in task context in that there is a valid current(), but
> running with preemption and/or interrupts and/or pagefaults disabled
> at that point, so in_task() objects. Think of it like from a kprobes
> handler callback, except maybe more temporary preemption blocking.
#define in_task() (!(preempt_count() & \
(NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET)))
So it doesn't care about preempt_disable(), and it doesn't care about
local_irq_disable(), it also doesn't care about local_bh_disable().
What it does care about are nmi_enter(), irq_enter() and __do_softirq().
next prev parent reply other threads:[~2017-01-19 22:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 9:57 [RFC][PATCH] x86: Verify access_ok() context Peter Zijlstra
2016-11-22 17:28 ` Andy Lutomirski
2016-11-22 19:37 ` Peter Zijlstra
2016-11-22 19:42 ` Linus Torvalds
2016-12-05 10:27 ` Peter Zijlstra
2017-01-16 20:27 ` David Smith
2017-01-16 21:14 ` Thomas Gleixner
2017-01-18 22:16 ` David Smith
2017-01-19 0:19 ` Andy Lutomirski
2017-01-19 15:37 ` David Smith
2017-01-20 8:24 ` Peter Zijlstra
2017-01-20 8:50 ` Thomas Gleixner
2017-01-19 18:12 ` Thomas Gleixner
2017-01-19 20:22 ` Frank Ch. Eigler
2017-01-19 20:50 ` Thomas Gleixner
2017-01-19 21:27 ` Frank Ch. Eigler
2017-01-19 22:20 ` Peter Zijlstra [this message]
2017-01-19 23:04 ` Thomas Gleixner
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=20170119222008.GI6515@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dsmith@redhat.com \
--cc=fche@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--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.