On Wed, Aug 23, 2017 at 10:38:51AM +0100, Alex Benn?e wrote:

Dave Martin [off-list ref] writes:

quoted

This patch implements support for saving and restoring the SVE
registers around signals.

A fixed-size header struct sve_context is always included in the
signal frame encoding the thread's vector length at the time of
signal delivery, optionally followed by a variable-layout structure
encoding the SVE registers.

Because of the need to preserve backwards compatibility, the FPSIMD
view of the SVE registers is always dumped as a struct
fpsimd_context in the usual way, in addition to any sve_context.

The SVE vector registers are dumped in full, including bits 127:0
of each register which alias the corresponding FPSIMD vector
registers in the hardware.  To avoid any ambiguity about which
alias to restore during sigreturn, the kernel always restores bits
127:0 of each SVE vector register from the fpsimd_context in the
signal frame (which must be present): userspace needs to take this
into account if it wants to modify the SVE vector register contents
on return from a signal.

FPSR and FPCR, which are used by both FPSIMD and SVE, are not
included in sve_context because they are always present in
fpsimd_context anyway.

For signal delivery, a new helper
fpsimd_signal_preserve_current_state() is added to update _both_
the FPSIMD and SVE views in the task struct, to make it easier to
populate this information into the signal frame.  Because of the
redundancy between the two views of the state, only one is updated
otherwise.  In order to avoid racing with a pending discard of the
SVE state, this flush is hoisted before the sigframe layout phase,
so that the layout and population phases see a consistent view of
the thread.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---

[...]

quoted

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 80ecb2d..e8674f6 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c

@@ -148,8 +148,6 @@ static void change_cpacr(u64 old, u64 new)
 		write_sysreg(new, CPACR_EL1);
 }

-#ifdef CONFIG_ARM64_SVE
-
 #define ZREG(sve_state, vq, n) ((char *)(sve_state) +		\
 	(SVE_SIG_ZREG_OFFSET(vq, n) - SVE_SIG_REGS_OFFSET))

@@ -191,6 +189,8 @@ static void fpsimd_to_sve(struct task_struct *task)
 		       sizeof(fst->vregs[i]));
 }

+#ifdef CONFIG_ARM64_SVE
+

Hmm have sve_to_fpsimd and fpsimd_to_sve only just started being used by
the generic code here?

Yes, the signal code now makes use of these via
fpsimd_signal_preserve_current_state() and
fpsimd_update_current_state(), with this patch.

[...]

quoted

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 4991e87..2694143 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c

[...]

quoted

+#ifdef CONFIG_ARM64_SVE
+
+static int preserve_sve_context(struct sve_context __user *ctx)
+{
+	int err = 0;
+	u16 reserved[ARRAY_SIZE(ctx->__reserved)];
+	unsigned int vl = current->thread.sve_vl;
+	unsigned int vq = 0;
+
+	BUG_ON(!sve_vl_valid(vl));
+	if (test_thread_flag(TIF_SVE))
+		vq = sve_vq_from_vl(vl);
+
+	memset(reserved, 0, sizeof(reserved));
+
+	__put_user_error(SVE_MAGIC, &ctx->head.magic, err);
+	__put_user_error(round_up(SVE_SIG_CONTEXT_SIZE(vq), 16),
+			 &ctx->head.size, err);
+	__put_user_error(vl, &ctx->vl, err);
+	BUILD_BUG_ON(sizeof(ctx->__reserved) != sizeof(reserved));
+	err |= copy_to_user(&ctx->__reserved, reserved, sizeof(reserved));
+
+	if (vq) {
+		/*
+		 * This assumes that the SVE state has already been saved to
+		 * the task struct by calling preserve_fpsimd_context().
+		 */
+		BUG_ON(SVE_SIG_REGS_SIZE(vq) !=
sve_state_size(current));

I think others have mentioned the excessive BUG_ON()s here but I think
you are planning on cleaning some up on the next version. Assuming
sve_vq_from_vl() can't give you an invalid answer from a
sve_vl_valid(vl) then I wouldn't expect this test to add much.

Agreed.  Some BUG_ON()s test for things that are now obviously true
by construction, which was not initially the case during development.
This one can go away.

I'm very interested in any BUG_ON() that you think can actually fire.
There _shouldn't_ be any of those, but the reasons are non-trivial in
some cases.

quoted

+		err |= copy_to_user((char __user *)ctx + SVE_SIG_REGS_OFFSET,
+				    current->thread.sve_state,
+				    SVE_SIG_REGS_SIZE(vq));
+	}
+
+	return err ? -EFAULT : 0;
+}
+
+static int restore_sve_fpsimd_context(struct user_ctxs *user)
+{
+	int err;
+	unsigned int vq;
+	struct fpsimd_state fpsimd;
+	struct sve_context sve;
+
+	if (__copy_from_user(&sve, user->sve, sizeof(sve)))
+		return -EFAULT;
+
+	if (sve.vl != current->thread.sve_vl)
+		return -EINVAL;
+
+	if (sve.head.size <= sizeof(*user->sve)) {
+		clear_thread_flag(TIF_SVE);
+		goto fpsimd_only;
+	}
+
+	BUG_ON(!sve_vl_valid(sve.vl));
+	vq = sve_vq_from_vl(sve.vl);
+
+	if (sve.head.size < SVE_SIG_CONTEXT_SIZE(vq))
+		return -EINVAL;
+
+	fpsimd_flush_task_state(current);
+	barrier();
+	set_thread_flag(TIF_FOREIGN_FPSTATE);
+	barrier();

What are you trying to achieve with barriers here? Is there a potential
interaction between flushing the state and setting the flag that the
compiler can't see? A comment should be added at least.

This is a tricky one -- I suppose I should definitely add comments,
since it took me 2-3 weeks to debug this and get it right the first time
around...

I'm trying to protect against a context switch during the copy_from_user
rewriting stale register data over the data we're copying from the user
signal frame.

In most places, I now disable preemption when writing into thread_struct,
to keep this can of worms firmly closed.

Here though, the code writes directly into thread_struct with
preemption enabled: in this one case the copy is a copy_from_user(),
and we can't disable preemption for that.  Other than this, the reasons
for this code being the way it is derive from Ard's deferred fpsimd
reload machinery (the TIF_FOREIGN_FPSTATE stuff), which is described in
more detail in fpsimd.c.


The reason for the difference from the old fpsimd code here is that the
SVE state may be unreasonably large to bounce via a buffer on the stack,
and the copy-in occurs while the thread is running.  In the ptrace case
(later on) the thread is guaranteed stopped, whereas for fpsimd the
state is small enough that we _can_ bounce it via the stack.

TIF_FOREIGN_FPSTATE may be cleared by the context switch code, but only
if fpsimd_flush_task_state() wasn't called since the last kernel entry
for current.  (See fpsimd_thread_switch().)

The context switch code may write the CPU registers over thread_struct,
but only if TIF_FOREIGN_FPSTATE is not set at sched-out time.
(fpsimd_thread_switch() again).

These dependencies are strictly intra-thread, since context-switch is
part of the same thread, so

	fpsimd_flush_task_state();
	barrier();
	set_thread_flag(TIF_FOREIGN_FPSTATE);
	barrier();
	copy_from_user(current->thread.sve_state, ...);

should be sufficient.

I prefer to avoid spuriously saving the SVE regs into thread_struct
when they may not already be live, so I don't set TIF_SVE until after
TIF_FOREIGN_FPSTATE is set.  (This is a cost saving rather than a
security issue -- only current's state can be in the registers, but the
extra SVE bits are definitely not worth saving.  In any case, it only
makes a difference to context switches in this narrow window.)

quoted

+
+	sve_alloc(current);
+	BUG_ON(SVE_SIG_REGS_SIZE(vq) != sve_state_size(current));
+	err = __copy_from_user(current->thread.sve_state,
+			       (char __user const *)user->sve +
+					SVE_SIG_REGS_OFFSET,
+			       SVE_SIG_REGS_SIZE(vq));
+	if (err)
+		return err;
+
+	barrier();
+	set_thread_flag(TIF_SVE);

Hmm and again. If this is about visibility of context when the thread
flag is read by other CPUs a barrier() on it's own is not enough as it
only stop local code re-organisation - do you actually mean smp_mb()?

Either way you need to document the potential race in a comment so the
reason can be understood.

The final barrier() isn't really needed, and the ordering of TIF_SVE
with the copy_from_user is unimportant unless I've missed something ...
so I may get rid of that.  TIF_SVE would affect context switch, but
only if TIF_FOREIGN_FPSTATE is clear or a ret_to_user occurs, neither
of which is possible after the second barrier().


Re smp_mb(), the only cross-thread ordering guarantees needed are for
ptrace (later in the series), since that runs in some thread operating
on a stopped thread that may have last run on some other CPU.  But this
is a general ptrace issue, not specifically related to SVE.  IIRC some
interaction between the ptrace core code and the scheduler's
manipulation of the task state and runqueue locks ensures safety in
that case without need for extra smp_mb() all over the place.

quoted

+
+fpsimd_only:
+	/* copy the FP and status/control registers */
+	/* restore_sigframe() already checked that user->fpsimd != NULL. */
+	err = __copy_from_user(fpsimd.vregs, user->fpsimd->vregs,
+			       sizeof(fpsimd.vregs));
+	__get_user_error(fpsimd.fpsr, &user->fpsimd->fpsr, err);
+	__get_user_error(fpsimd.fpcr, &user->fpsimd->fpcr, err);
+
+	/* load the hardware registers from the fpsimd_state structure */
+	if (!err)
+		fpsimd_update_current_state(&fpsimd);
+
+	return err;
+}

[...]

Cheers
---Dave