dtrace/arm64: de-pessimize dtrace_copy

[freebsd_dev.thsi.be]

Summary

When DTrace catches a data abort exception it resumes execution on the
next instruction. If a probe executes copyinto from unmapped memory,
then dtrace_copy keeps faulting on successive bytes until the loop
counter is exhausted. Detect the situation by witnessing the absence
of zero-extension from an aborted unprivileged load.

[freebsd_dev.thsi.be]

I failed at my attempt to produce a reliable testcase, so I ended up hacking a debug counter in dtrace_trap. Running dwatch -X read on a idle system with simple ssh activity went from this counter raising by the several thousands to a couple at a time.

[markj]

sys/cddl/dev/dtrace/aarch64/dtrace_asm.S

128

Does this routine need to be updated too?

[freebsd_dev.thsi.be]

I think so. In Illumos, the condition is well checked. Would you like this review to include the a fix for that? If yes, then I'll update D59280 to put a fix for arm32 too.
Also I believe that riscv is affected, but I don't have hw or the will to delve into riscv emulation and asm manuals right now.

(I'd like to make sure the copyout part works. but I need a bit of time to go around it)

[markj]

In D59341#1361662, @freebsd_dev.thsi.be wrote:

I think so. In Illumos, the condition is well checked. Would you like this review to include the a fix for that? If yes, then I'll update D59280 to put a fix for arm32 too.

It'd be nice to fix both, yeah. Sorry, I already committed the 32-bit arm patch to main, I forgot that it has the same problem.

Also I believe that riscv is affected, but I don't have hw or the will to delve into riscv emulation and asm manuals right now.

(I'd like to make sure the copyout part works. but I need a bit of time to go around it)

Would you be willing to file an issue for that in bugzilla? We can try to get the riscv folks to take a look.

[freebsd_dev.thsi.be]

optimize dtrace_copystr
adding a child revision to take care of copyout/copyoutstr.