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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- 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 sandbox 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. The ECAPMODE value needs to be provided after sigreturn, I presume it's not possible to insert it there? > > 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 stash 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. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273929-227-pBBup9qo94>