Stack unwinding robustness fixes for RISC-V.
ClosedPublic
Actions

Authored by jhb on Nov 24 2020, 9:48 PM.

Details

Reviewers

Commits

rS368454: Stack unwinding robustness fixes for RISC-V.

Summary

Push the kstack_contains check down into unwind_frame() so that it is honored by DDB and DTrace.
Check that the trapframe for an exception frame is contained in the traced thread's kernel stack for DDB traces.

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 35196
Build 32142: arc lint + arc unit

jhb requested review of this revision.Nov 24 2020, 9:48 PM

jhb created this revision.

jhb added reviewers: mhorne, jrtc27, markj.

markj added inline comments.

sys/cddl/dev/dtrace/riscv/dtrace_isa.c
93	This will have the same problem that @andrew mentioned in the arm64 review: nothing prevents one from enabling an FBT probe on unwind_frame().

sys/cddl/dev/dtrace/riscv/dtrace_isa.c
93	The same is true of dtrace_getpcstack and all manner of other functions, surely? Play stupid games, win stupid prizes, and all that. But in an ideal world we'd tell you to go away if you tried that.

sys/cddl/dev/dtrace/riscv/dtrace_isa.c
93	fbt_excluded() tries to exclude such cases. If you load DTrace as a set of kernel modules, as opposed to compiling it into the kernel, it is also smart enough to not create probes in its own kernel modules. This works fine on amd64: you can reliably enable all FBT probes in the kernel. On other platforms I wouldn't trust it to work because of issues like this, but in general you're not supposed to be able to crash the system by enabling arbitrary probes.