arm64: Support passing more registers to signals

[andrew]

Summary

To support recent extensions to the Arm architecture we may need to
store more or larger registers when sending a signal.

To support this create a list of these extra registers. Userspace that
needs to access a register in the signal handler can then walk the list
to find the correct register struct and read/write its contents.

Sponsored by: Arm Ltd

[markj]

sys/arm64/arm64/exec_machdep.c

618

627

Presumably this will become a real loop in a later revision.

[kib]

sys/arm64/arm64/exec_machdep.c

618

Are there any requirements on the contexts? For instance, should the mc_ptr be aligned, should sizes be dividable by sizeof(long)?

627

This is not an infinite uninterruptible loop induced by malicious userspace only because ctx_size is 32bit. I suggest to add a check for the element counter and limit it arbitrary, say to 100 elements.

[imp]

So I have a question.
How does this interact with the getcontext/setcontext calls?
If I'm reading it correctly, do don't do anything for them, so we can lose context if someone were using these manually outside of the signal context.
How does that work? We can't save extra stuff for them because there's not room in mcontext/ucontext to do that.

I'm thinking about how the heck I'm going to emulate this in bsd-user... we have this issue in the small on 32-bit arm with fp registers.

[imp]

The man page says, in describing setcontext():

If ucp was initialized by getcontext(), then execution continues as if
the original getcontext() call had just returned (again).

which isn't true if the SVE registers have been changed in the mean time, no?

[kib]

In D43302#987292, @imp wrote:

The man page says, in describing setcontext():

If ucp was initialized by getcontext(), then execution continues as if
the original getcontext() call had just returned (again).

which isn't true if the SVE registers have been changed in the mean time, no?

It is same as YMM/ZMM (or any other XSAVE extended state) on x86_64 already. getcontext() cannot handle them without breaking ABI for the ucontext_t, and ucontext_t is also by design is not extensible. I added getcontextx() etc to libc exactly to handle this problem. I think arm64 should provide reg_context-enabled getcontextx()/setcontextx(), same as amd64. Also libthr thr_sig.c would be handled automatically then.

[imp]

In D43302#987294, @kib wrote:

In D43302#987292, @imp wrote:

The man page says, in describing setcontext():

If ucp was initialized by getcontext(), then execution continues as if
the original getcontext() call had just returned (again).

which isn't true if the SVE registers have been changed in the mean time, no?

It is same as YMM/ZMM (or any other XSAVE extended state) on x86_64 already. getcontext() cannot handle them without breaking ABI for the ucontext_t, and ucontext_t is also by design is not extensible. I added getcontextx() etc to libc exactly to handle this problem. I think arm64 should provide reg_context-enabled getcontextx()/setcontextx(), same as amd64. Also libthr thr_sig.c would be handled automatically then.

A caveat should be added to the man page. I'll do that now.

Since getcontext and setcontext are marked as obsolete / removed from POSIX, the x versions are likely fine. The x86 ones are implemented with a sysarch that gets the state, which bsd-user can emulate easily enough. 32-bit arm has it and I think we're mostly compliant there (I'll have to double check the bsd-user impl).

[andrew]

sys/arm64/arm64/exec_machdep.c

627

See D43307 for how it will be used. There will be a check for the size when handling each context.

We should only ever see one of each context type so will add a check to D43307 to do so (it will be an unused variable here).

[andrew]

• Style fix
• Add an alignment check on contexts

[andrew]

Move sigreturn code to set_mcontext to be used in more syscalls