linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Rework valid_user_regs
Date: Wed, 10 Feb 2016 12:31:10 +0000	[thread overview]
Message-ID: <20160210123110.GD2632@leverpostej> (raw)
In-Reply-To: <20160210115853.GG1052@arm.com>

On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> Hi Mark,
> 
> On Tue, Feb 09, 2016 at 06:11:41PM +0000, Mark Rutland wrote:
> > +/*
> > + * Bits which are architecturally RES0 per ARM DDI 0487A.h
> > + * The kernel matches the HW policy. Userspace cannot use these until they have
> > + * an architectural meaning.
> > + */
> > +#define SPSR_EL1_AARCH64_RES0_BITS \
> > +	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(19, 10) | \
> > +	 GENMASK_ULL(5, 5))
> > +#define SPSR_EL1_AARCH32_RES0_BITS \
> > +	(GENMASK_ULL(63,32) | (GENMASK_ULL(23, 22)))
> 
> The J bit (24) is also RES0 and the E bit (9) can be RES0/RES1 depending
> on what the CPU supports.

>From a quick look, J is always RES0 for ARMv8. I'll add that to the
mask.

E is a bit more complex; I'll see about handling that dynamically in
valid_compat_user_regs.

> It also might be worth negating these in the definition, rather than
> on every use.

Does that make anything clearer? They're constants which get used once
each, and SPSR_EL1_AARCH*_MASK wouldn't make it clear what the bits
actually are.

If you have a better suggestion for a name I'm happy to change it.

> > +static int valid_aa32_regs(struct user_pt_regs *regs)
> 
> valid_compat_user_regs

Ok

> > +static int valid_aa64_regs(struct user_pt_regs *regs)
> 
> valid_native_user_regs

Ok.

> > +{
> > +	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;
> > +	}
> 
> 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.

I couldn't spot anything in the ARM ARM regarding PSR bit groups,; I was
cargo-culting from the existing code. I'm more than happy to make the
PSR_* groups an aarch32/compat thing.

> > +int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> > +{
> > +	if (is_compat_thread(task_thread_info(task)))
> 
> is_compat_task

Can't do; is_compat_task() takes no task_struct and assumes we're asking
about current (which doesn't work for the ptrace cases).

We could add a new helper for this, but I think that should be future
cleanup as we'd want to alter the other uses:

[mark at leverpostej:~/src/linux]% git grep is_compat_thread origin/master
origin/master:arch/arm64/include/asm/compat.h:static inline int is_compat_thread(struct thread_info *thread)
origin/master:arch/arm64/include/asm/compat.h:static inline int is_compat_thread(struct thread_info *thread)
origin/master:arch/arm64/include/asm/processor.h:       if (is_compat_thread(task_thread_info(t)))                      \
origin/master:arch/arm64/kernel/hw_breakpoint.c:        return tsk && is_compat_thread(task_thread_info(tsk));
origin/master:arch/arm64/kernel/perf_regs.c:    if (is_compat_thread(task_thread_info(task)))
origin/master:arch/arm64/kernel/process.c:                      if (is_compat_thread(task_thread_info(p)))
origin/master:arch/arm64/kernel/process.c:      tpidrro = is_compat_thread(task_thread_info(next)) ?
origin/master:arch/arm64/kernel/ptrace.c:       else if (is_compat_thread(task_thread_info(task)))

I'm happy to look at cleaning that up as a later patch/series.

Thanks,
Mark.

  reply	other threads:[~2016-02-10 12:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 18:11 [PATCH] arm64: Rework valid_user_regs Mark Rutland
2016-02-10 11:58 ` Will Deacon
2016-02-10 12:31   ` Mark Rutland [this message]
2016-02-10 14:23     ` Peter Maydell
2016-02-10 14:43       ` Will Deacon
2016-02-10 16:01         ` Mark Rutland
2016-02-10 16:04           ` Will Deacon
2016-02-10 16:05             ` Mark Rutland
2016-02-10 16:36               ` Will Deacon

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=20160210123110.GD2632@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).