[PATCH] arm64: Rework valid_user_regs

[Will Deacon]

On Wed, Feb 10, 2016 at 04:05:50PM +0000, Mark Rutland wrote:
> On Wed, Feb 10, 2016 at 04:04:21PM +0000, Will Deacon wrote:
> > On Wed, Feb 10, 2016 at 04:01:27PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > > > > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > > > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > > > > >> I think we should err on the side of caution and nuke SS and IL for both
> > > > > >> native and compat too, although that seems a odds with the PSR_s mask.
> > > > > >> I wonder how relevant those PSR groups are in ARMv8...
> > > > > >
> > > > > > Ok.
> > > > > 
> > > > > If you nuke SS does that have any side effects in the case
> > > > > of (for instance) interactions between ptrace single step
> > > > > and ptrace syscall tracing? (ie do we ever end up in a situation
> > > > > where the ptracer can read a PSR for the debuggee which has
> > > > > SS set? if so then it should be able to write back the PSR
> > > > > it has just read without any bits being unset.)
> > > > 
> > > > I don't think so -- the signal dispatch logic "fast-forwards" the stepping
> > > > state machine so that we step into the signal handler, therefore the SS
> > > > bit should always be clear on entry afaict.
> > > 
> > > That handles entry, but what about exit?
> > > 
> > > Is there are a guarantee that we won't call user_enable_single_step() if
> > > the return path is traced?
> > 
> > Why would that be a problem? I think I'm missing your point...
> 
> We would nuke the SS bit if the tracing happens after
> user_enable_single_step, if the tracer fiddled with pstate at all. So
> you wouldn't get the single stepping you expected.
> 
> Maybe I'm missing some reason this is prevented by construction.

Ok, for some reason I thought this was all about signal handling, but I
now see Peter was referring to general ptrace register manipulation.

In which case, we could force SS to zero if TIF_SINGLESTEP is not set
on the tracee, otherwise letting it be set. Ultimately, MDSCR_EL1.SS
prevents PSTATE.SS from taking effect if !TIF_SINGLESTEP, but it's
worth cleaning this up imo.

Will