Date: Tue, 19 Sep 2023 00:11:35 +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-pBBup9qo94@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 #3 from Kyle Evans <kevans@freebsd.org> --- (In reply to David Chisnall from comment #2) > I don't have a *minimal* reproducer, but I've been porting the Verona san= dbox code to AArch64: Right, sorry, I meant that I've attached what I believe to be a minimal reproducer of your report. > I could work around this if the original x0 register were either provided= in the siginfo or if it were provided in another caller-save register. Th= e ECAPMODE value needs to be provided after sigreturn, I presume it's not p= ossible to insert it there?=20=20 > > Copying x0 over x9 in the syscall enter routine would be fine, I think. I can't see any reason off-hand that cpu_fetch_syscall_args() couldn't stas= h a copy of x0 off in x9 to be used in set_mcontext(). I can't imagine a situation where the error (be it ENOSYS, ECAPMODE) really 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 preserve = that in the mcontext. --=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-pBBup9qo94>