arm64: Support passing more registers to signals
ClosedPublic
Actions

Authored by andrew on Jan 4 2024, 12:31 PM.

Details

Reviewers

kib
markj
manu

Group Reviewers

arm64

Commits

rG254d54f0733f: arm64: Support passing more registers to signals
rG7e6437c08415: arm64: Support passing more registers to signals

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.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 56516
Build 53404: arc lint + arc unit

Event Timeline

andrew created this revision.Jan 4 2024, 12:31 PM

Herald added a reviewer: manu. · View Herald TranscriptJan 4 2024, 12:31 PM

Herald added subscribers: emaste, imp. · View Herald Transcript

andrew requested review of this revision.Jan 4 2024, 12:31 PM

Harbormaster completed remote builds in B55232: Diff 132249.Jan 4 2024, 12:31 PM

andrew added a child revision: D43303: arm64: Don't trap SVE to EL2.Jan 4 2024, 12:32 PM

markj accepted this revision.Jan 4 2024, 2:24 PM

markj added inline comments.

sys/arm64/arm64/exec_machdep.c
616
625	Presumably this will become a real loop in a later revision.

This revision is now accepted and ready to land.Jan 4 2024, 2:24 PM

kib added inline comments.Jan 4 2024, 3:23 PM

sys/arm64/arm64/exec_machdep.c
616	Are there any requirements on the contexts? For instance, should the mc_ptr be aligned, should sizes be dividable by sizeof(long)?
625	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.

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.

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?

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.

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 added inline comments.Mar 6 2024, 5:06 PM

sys/arm64/arm64/exec_machdep.c
625	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).