Date: Tue, 19 Sep 2023 08:54:01 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations Message-ID: <bug-273929-227-ScUMkzMZ0Z@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273929-227@https.bugs.freebsd.org/bugzilla/> References: <bug-273929-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273929 --- Comment #4 from David Chisnall <theraven@FreeBSD.org> --- (In reply to Kyle Evans from comment #3) > I can't imagine a situation where the error (be it ENOSYS, ECAPMODE) real= ly matters that much, but if it did we could presumably also fence off x10 = as flag indicating whether x0 has been set to the return value or not and p= reserve that in the mcontext. Part of the problem is that I haven't managed to merge the SIGCAP patches (= help there from someone who understands the signal delivery mechanism would be welcome!) and so currently SIGTRAP is overloaded here to mean both: - Here is a signal that the program can catch and handle and use to emulat= e. - Here is something that the debugger can watch for and help when debugging Capsicum violations. For the second case, x0 needs to contain ENOTCAPABLE / ECAPMODE so that code around it can work well with graceful fallback (e.g. we're failing because = of cap mode, try an openat thing instead). For the first case, we want the original x0 and *may* replace the return value with a success value if we emulate correctly but may also pass it on for the wrapped code to try its o= wn emulation. The nice thing is that anything in the first category is definitely writing architecture-specific (and os-specific) code and so can look in x9. I'm not sure when the extra value in x10 is useful. If x9 is set unconditionally f= or capsicum-triggered SIGTRAP in newer kernels, you still can't use a value in= x10 to detect whether it's happened because, if it hasn't, x10 may still have whatever value you choose as a marker, left over from whatever the caller p= ut in there. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273929-227-ScUMkzMZ0Z>