[PATCH v2 2/4] arm64/signal: Include TPIDR2 in the signal context

[Mark Brown]

On Fri, Nov 18, 2022 at 01:55:53PM +0000, Will Deacon wrote:
> On Tue, Nov 15, 2022 at 04:42:14PM +0000, Mark Brown wrote:

> > > I see, but having the usual '<' check wouldn't preclude us from doing
> > > what you suggest above, whilst also giving us some flexibility in case
> > > things turn out differently from how we expected.

> > This actually also how we validate the base fpsimd_context -
> > while there is a < check in the switch statement in
> > parse_user_sigframe() but we also have an exact size check
> > near the top of restore_fpsimd_context() which gets called from

> Hmm, good point about fpsimd, it looks at magic/size twice which is
> definitely wrong (userspace could even change those values in between!).

> So I'd vote for removing the checks from restore_fpsimd_context() which
> raises the same question we were discussing initially: should the check
> in parse_user_sigframe() require an exact size match or instead truncate
> the structure on the stack by only copying a prefix into the kernel?

I think it might be best to go the other way and remove the size
checks from parse_user_sigframe() entirely and put them into the
frame type specific functions so that parse_user_sigframe() looks
the same for all frame types.  We should make sure that the
individual frame type functions don't re-read the magic and size
though, only reading the additional frame type specific data and
doing whatever validation makes sense.

> I'm actually warming more towards an exact check now that we've spoken
> about it a bit... What do you think?

I'm more inclined towards exact checks, it seems safer.  It's
hard to see how we'd use any extensibility in a way that doesn't
go bad in some situation or other if the frame isn't designed to
be variably sized from the start, it's a lot easier to add a new
frame safely than to extend an existing one.

I'll send a new version fixing all the other issues you pointed
out and with size the check code as is (apart from anything else
I already prepared it) and then look at fixing up the behaviour
for FPSIMD and generally around parse_user_sigframe() incrementally.
Hopefully that's OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221118/1534368c/attachment.sig>