[PATCHv3] arm64: Rework valid_user_regs

[mark.rutland@arm.com (Mark Rutland)]

On Tue, Mar 01, 2016 at 01:40:44PM +0000, Will Deacon wrote:
> On Tue, Mar 01, 2016 at 01:08:33PM +0000, Peter Maydell wrote:
> > On 1 March 2016 at 12:47, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Tue, Feb 16, 2016 at 06:20:05PM +0000, Will Deacon wrote:
> > >> > +static int valid_native_regs(struct user_pt_regs *regs)
> > >> > +{
> > >> > +   regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
> > >> > +
> > >> > +   if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
> > >> > +       (regs->pstate & PSR_D_BIT) == 0 &&
> > >> > +       (regs->pstate & PSR_A_BIT) == 0 &&
> > >> > +       (regs->pstate & PSR_I_BIT) == 0 &&
> > >> > +       (regs->pstate & PSR_F_BIT) == 0) {
> > >> > +           return 1;
> > >> > +   }
> > >> > +
> > >> > +   /* Force PSR to a valid 64-bit EL0t */
> > >> > +   regs->pstate &= PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > >>
> > >> Can we not just zap the pstate to PSR_MODE_EL0t and be done with it?
> > >
> > > I'm worried that some userspace might be relying on these being
> > > preserved.
> > 
> > This function is called as part of signal-return, right?
> > You clearly can't just zap the flag registers in that code
> > path, because you'd then be corrupting the flags of the
> > bit of userspace code that was interrupted by the signal.
> > (Or am I missing something?)
> 
> Well, it would only occur if the signal handler had tried to set pstate
> to an invalid value. That said, it is a change in behaviour, so we can
> leave it as Mark has suggested.

Ok. Assuming you're happy with that I'll post a v4 shortly with the
AArch32 comment, and the forced AArch64 state left as in v3.

Thanks,
Mark.