LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: unprivileged use of MSR_SE
Date: Thu, 20 Mar 2008 00:43:00 -0700 (PDT)	[thread overview]
Message-ID: <20080320074300.30D4026F995@magilla.localdomain> (raw)
In-Reply-To: Paul Mackerras's message of  Thursday, 20 March 2008 15:10:18 +1100 <18401.58282.992971.923754@cargo.ozlabs.ibm.com>

> No and no.

Good and good!

> On ppc32 there is a sys_debug_setcontext system call that is there to
> allow a process to debug itself.  It does a setcontext and optionally
> sets the MSR_SE or MSR_BE bit.  We don't have it on ppc64 for some
> reason (we should add it).

Wacky.  I only looked in signal_64.c, so I didn't notice this.

> The only MSR bit that sigreturn copies from the signal frame back into
> the MSR is the MSR_LE (little-endian) bit.

So it is.  I looked right at that and saw something different.  It must
have been my psychic abilities trying to tell me about sys_debug_setcontext.

> > Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
> 
> It already does AFAICS.

But sys_debug_setcontext doesn't.  That is, it has user semantics
(sig_dbg_op.dbg_value) that mean setting MSR_SE.  I take it you mean to
preserve that user feature.  For the issue I've been talking about that
makes it equivalent to the x86 popf case.

For example, use syscall tracing to stop at the exit from
sys_debug_setcontext (in a call with dbg->dbg_value!=0).
MSR_SE is set, as it should be.  Now using PTRACE_CONT or PTRACE_SYSCALL
will clear MSR_SE and resume, breaking the user's behavior.

For the analogous problem on x86, we keep a flag saying whether MSR_SE was
set "artificially" by ptrace or was set "for real" in the user state.  We
use a TIF bit, but whatever is optimal.  In user_enable_single_step, set
the forced-SE flag if MSR_SE was clear and don't if it was already set.
In user_disable_single_step, clear the forced-SE flag and only if it was
set, clear MSR_SE.  With that, debugger-step and user-self-step can cooexist.

> OK, I found MSR_DEBUGCHANGE, it's in ptrace.c. :)  So it only applies
> to attempts to change the MSR of a process using ptrace.  So, what you
> want is just to disallow changing MSR via PTRACE_POKEUSR or
> equivalent, then?

If there is no way like sys_debug_setcontext to set MSR_SE as proper user
state, then yes.  If it is possible for a user task to set its own MSR_SE,
then I'd like the forced-SE flag as above.  Then get_user_msr should mask
off MSR_SE when forced-SE is set, and set_user_msr should clear forced-SE
when MSR_SE is set via user_regset (ptrace).  That way user_regset calls
can fetch and restore the complete user-visible state, including the state
just after executing a sys_debug_setcontext requesting self-step.


Thanks,
Roland

  reply	other threads:[~2008-03-20  7:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20  0:24 unprivileged use of MSR_SE Roland McGrath
2008-03-20  4:10 ` Paul Mackerras
2008-03-20  7:43   ` Roland McGrath [this message]
2008-03-20  4:15 ` Paul Mackerras

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=20080320074300.30D4026F995@magilla.localdomain \
    --to=roland@redhat.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox