Page MenuHomeFreeBSD

Check that the frame pointer is within the current stack.
ClosedPublic

Authored by jhb on Nov 24 2020, 9:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 17 2025, 9:30 PM
Unknown Object (File)
Jan 12 2025, 1:02 AM
Unknown Object (File)
Jan 8 2025, 3:12 AM
Unknown Object (File)
Dec 28 2024, 9:37 PM
Unknown Object (File)
Dec 28 2024, 2:52 PM
Unknown Object (File)
Oct 5 2024, 3:51 PM
Unknown Object (File)
Sep 29 2024, 5:51 PM
Unknown Object (File)
Sep 29 2024, 5:51 PM
Subscribers

Details

Summary

This same check is used on other architectures. Previously this would
permit a stack frame to unwind into any arbitrary kernel address
(including unmapped addresses).

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 35015
Build 32000: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Nov 24 2020, 9:49 PM
sys/cddl/dev/dtrace/aarch64/dtrace_isa.c
91

This was changed in rS333570 as unwind_frame could be probed by the FBT provider. It might be enough to exclude it from being probed in fbt_provide_module_function

sys/cddl/dev/dtrace/aarch64/dtrace_isa.c
91

I think that would be fine. Alternately, perhaps unwind_frame() could move to stack.h?

sys/cddl/dev/dtrace/aarch64/dtrace_isa.c
91

Hmm, risc-v would need the same approach as I have made it also use unwind_frame. Do you have a preference Mark on how to fix it?

sys/cddl/dev/dtrace/aarch64/dtrace_isa.c
91

I think I prefer to explicitly exclude unwind_frame() from FBT by modifying fbt_provide_module_function() for the relevant arches. All of the solutions (keep the code as-is, make unwind_frame() inlinable, exclude unwind_frame() from FBT) are kind of fragile, but modifying FBT at least makes it easy to identify these problematic functions.

  • Add unwind_frame to fbt_excluded.
This revision was not accepted when it landed; it landed in state Needs Review.Dec 8 2020, 6:01 PM
This revision was automatically updated to reflect the committed changes.