unprivileged use of MSR_SE

unprivileged use of MSR_SE

[Roland McGrath]

Are there any powerpc instructions that can read or change the MSR
explicitly from user mode?  Any that can see or affect the MSR_SE bit?

e.g. x86 has pushf/popf unprivileged instructions, with which a user
program can both see the single-step flag set, and enable single-step for
its own next instruction (presumably when it has a handler for SIGTRAP).
This actually gets used in arcane places.

I recall being told before there's no unprivileged way to see or touch
MSR_SE.  But it looks to me like a user program can set the bit in a
sigcontext and sigreturn to set it.  Is that intentionally supported?
Or could sigreturn ignore the MSR_SE bit without breaking any strange user?

On x86 do we some machinations so that PTRACE_GETREGS et al show the
single-step bit set if user-mode itself had set it, but not if
PTRACE_SINGLESTEP set it.  If you use PTRACE_SETREGS et al to set the
single-step bit, then it stays set even if you use PTRACE_CONT.

I'd like to clean this up for powerpc too.  If there is no way at all for
user-mode to set MSR_SE, then it doesn't much matter whether it shows up
when ptrace reads it--ptrace just needs to ignore attempts to set it.  So
if there's no reason not to, what I would do is remove MSR_SE from the
MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.

Does that make sense?


Thanks,
Roland

Re: unprivileged use of MSR_SE

[Paul Mackerras]

Roland McGrath writes:

> Are there any powerpc instructions that can read or change the MSR
> explicitly from user mode?  Any that can see or affect the MSR_SE bit?

No and no.

> e.g. x86 has pushf/popf unprivileged instructions, with which a user
> program can both see the single-step flag set, and enable single-step for
> its own next instruction (presumably when it has a handler for SIGTRAP).
> This actually gets used in arcane places.

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).

> I recall being told before there's no unprivileged way to see or touch
> MSR_SE.  But it looks to me like a user program can set the bit in a
> sigcontext and sigreturn to set it.  Is that intentionally supported?

The only MSR bit that sigreturn copies from the signal frame back into
the MSR is the MSR_LE (little-endian) bit.  I just checked the various
forms (rt/non-rt, 32/64 bit) and they all do that as far as I can
see.  If you see a path where we restore more than that let me know.
We do also use the MSR_VEC and MSR_SPE bits in the MSR image in the
signal frame to indicate whether the frame contains altivec or SPE
bits, but those bits don't get put back into the MSR on signal return.

> Or could sigreturn ignore the MSR_SE bit without breaking any strange user?

It already does AFAICS.

> On x86 do we some machinations so that PTRACE_GETREGS et al show the
> single-step bit set if user-mode itself had set it, but not if
> PTRACE_SINGLESTEP set it.  If you use PTRACE_SETREGS et al to set the
> single-step bit, then it stays set even if you use PTRACE_CONT.
> 
> I'd like to clean this up for powerpc too.  If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it.  So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.

MSR_DEBUGCHANGE is already gone.  I don't mind making sigreturn clear
MSR_SE (should setcontext do so too?), but please give me a nice
detailed explanation why we should do that, and why we don't want to
do what we do at present, which is that sigreturn doesn't affect the
process's MSR at all (well, just the LE bit).

Paul.

Re: unprivileged use of MSR_SE

[Roland McGrath]

> 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

Re: unprivileged use of MSR_SE

[Paul Mackerras]

Roland McGrath writes:

> I'd like to clean this up for powerpc too.  If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it.  So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.

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?

Paul.