From: Oleg Nesterov <oleg@redhat.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
peterz@infradead.org, Jim Keniston <jkenisto@us.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
torvalds@linux-foundation.org
Subject: Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
Date: Wed, 20 Jun 2012 19:15:59 +0200 [thread overview]
Message-ID: <20120620171559.GA22320@redhat.com> (raw)
In-Reply-To: <20120618120642.GA4629@linux.vnet.ibm.com>
On 06/18, Srikar Dronamraju wrote:
>
> > My concern is, are you sure an evil user can't confuse uprobes and
> > do something bad?
> >
> > Just to explain what I mean. For example, we certainly do not want
> > to allow to probe the "syscall" insn, at least with the current
> > implementation. So I assume that validate_insn_64bits("syscall")
> > must fail.
> >
> > Are you sure that validate_insn_32bits("syscall") will fail too?
> >
> > Of course, I am not asking about "syscall" in particular. In general,
> > suppose that, say, validate_insn_64bits() returns true. Are you sure
> > this insn can't do something different and harmful if it is executed
> > by __USER32_CS task?
> >
>
> validate_insn_64bits can return fail for two cases.
> 1. Few opcodes that uprobes refuses to place probes.
> 2. opcodes that are invalid from a 64 perspective.
>
> validate_insn_32bits() can return fail for similar reasons.
>
> The first set is a common set between validate_insn_64bits /
> validate_insn_32bits. This includes the syscall, lock prefix, etc.
>
> Coming to the second set, there can be an instruction that is valid for
> 64 bit and not valid for 32 bit.
>
> If the instruction is valid for 32 bit set but invalid instruction for
> 64 bit, and is part of a 32 bit executable file but was mapped by a 64
> bit process. We would allow it to be probed since we only check for 32
> bit set. [Assuming it runs till a breakpoint hit;] I assume singlestep
> should generate a SIGILL signal since its not a valid 64 bit
> instruction. However this behaviour is on par with the behaviour if the
> probe was not hit too. i.e Once this invalid instruction was executed,
> It would have generated SIGILL. The same should hold true for a 32 bit
> invalid instruction in a 64 bit executable mapped into 32 bit process.
SIGILL (invalid insn) is fine, I was worried about the possibility
to allow to execute the valid (from CPU pov) but "dangerous" (from
uprobes pov) insn.
> Please do let me know if my understanding is incorrect or if there are
> loopholes
Well, you understand this indefinitely better than me ;) If you do not
see any hole then everything should be fine, I think.
> Again, this is all dependent on the ability to detect the executable
> type from the inode.
Yes... I am still not sure about this. But again, I am not arguing,
just I do not know.
Oleg.
prev parent reply other threads:[~2012-06-20 17:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 9:32 [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn() Ananth N Mavinakayanahalli
2012-06-08 9:32 ` Ananth N Mavinakayanahalli
2012-06-08 9:34 ` [PATCH v2 2/2] [POWERPC] uprobes: powerpc port Ananth N Mavinakayanahalli
2012-06-08 9:34 ` Ananth N Mavinakayanahalli
2012-06-08 14:58 ` [tip:perf/core] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn() tip-bot for Ananth N Mavinakayanahalli
2012-06-11 16:12 ` [PATCH v2 1/2] " Oleg Nesterov
2012-06-11 16:12 ` Oleg Nesterov
2012-06-11 19:09 ` Q: a_ops->readpage() && struct file Oleg Nesterov
2012-06-11 19:09 ` Oleg Nesterov
2012-06-13 9:58 ` Peter Zijlstra
2012-06-13 9:58 ` Peter Zijlstra
2012-06-13 19:19 ` Oleg Nesterov
2012-06-13 19:19 ` Oleg Nesterov
2012-06-12 16:54 ` [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn() Srikar Dronamraju
2012-06-12 16:54 ` Srikar Dronamraju
2012-06-12 17:43 ` Oleg Nesterov
2012-06-12 17:43 ` Oleg Nesterov
2012-06-13 19:15 ` Oleg Nesterov
2012-06-13 19:15 ` Oleg Nesterov
2012-06-14 11:45 ` Srikar Dronamraju
2012-06-14 11:45 ` Srikar Dronamraju
2012-06-14 18:19 ` Oleg Nesterov
2012-06-14 18:19 ` Oleg Nesterov
2012-06-15 12:33 ` Srikar Dronamraju
2012-06-16 18:05 ` Oleg Nesterov
2012-06-18 12:06 ` Srikar Dronamraju
2012-06-20 17:15 ` Oleg Nesterov [this message]
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=20120620171559.GA22320@redhat.com \
--to=oleg@redhat.com \
--cc=ananth@in.ibm.com \
--cc=hpa@zytor.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=srikar@linux.vnet.ibm.com \
--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.