History log of /freebsd/sys/cddl/dev/kinst/kinst.c (Results 1 – 11 of 11)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# fdeb273d 23-Nov-2024 Mark Johnston <markj@FreeBSD.org>

dtrace: Add some more annotations for KMSAN

- Don't allow FBT and kinst to instrument the KMSAN runtime.
- When fetching data from the traced thread's stack, mark it as
initialized. It may well b

dtrace: Add some more annotations for KMSAN

- Don't allow FBT and kinst to instrument the KMSAN runtime.
- When fetching data from the traced thread's stack, mark it as
initialized. It may well be uninitialized, but as dtrace permits
arbitrary inspection of kernel memory, it isn't very useful to raise
KMSAN reports.
- Mark data copied in from userspace as initialized, as we do for
copyin() etc. using interceptors.

MFC after: 2 weeks

show more ...


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0
# 5b701ed1 19-Jul-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: start moving towards per-probe trampolines

Using per-CPU and per-thread trampolines is expensive and error-prone,
since we're rewriting the same memory blocks constantly. Per-probe
trampoline

kinst: start moving towards per-probe trampolines

Using per-CPU and per-thread trampolines is expensive and error-prone,
since we're rewriting the same memory blocks constantly. Per-probe
trampolines solve this problem by giving each probe its own block of
executable memory, which more or less remains the same after the initial
write.

What this patch does, is get rid of the initialization code which
allocates a trampoline for each thread, and instead let each port of
kinst allocate a trampoline for each new probe created. It also sets up
the infrastructure needed to support the new trampoline scheme.

This change is not currently supported on amd64, as the amd64 port needs
further changes to work, so this is a temporary/gradual patch to fix the
riscv and arm64 ports.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40962

show more ...


# eb1413c9 19-Jul-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: exclude cpu_switch

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40985


# 9310bf54 04-Jul-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: update LICENSE headers

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40875


# d434607b 03-Jun-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: use bool where appropriate

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40412


# 5c134fba 26-May-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: fix memcpy() tracing crash

Tracing memcpy() would crash the kernel, because we'd also trace the
memcpy() calls from kinst_invop(). To fix this, introduce kinst_memcpy()
whose arguments are 'v

kinst: fix memcpy() tracing crash

Tracing memcpy() would crash the kernel, because we'd also trace the
memcpy() calls from kinst_invop(). To fix this, introduce kinst_memcpy()
whose arguments are 'volatile', so that we avoid having the compiler
replace it with a regular memcpy().

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40284

show more ...


# 9c80ad68 26-May-2023 Christos Margiolis <christos@FreeBSD.org>

kinst: add kinst_excluded()

Exclude functions that are not safe-to-trace.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
ifferential Revision: https://reviews.f

kinst: add kinst_excluded()

Exclude functions that are not safe-to-trace.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
ifferential Revision: https://reviews.freebsd.org/D39229

show more ...


Revision tags: release/13.2.0
# 84d7fe4a 08-Dec-2022 Mark Johnston <markj@FreeBSD.org>

kinst: Add per-CPU interrupt trampolines

In the common case, kinst emulates a traced instruction by copying it to
a trampoline, where it is followed by a jump back to the original code,
and pointing

kinst: Add per-CPU interrupt trampolines

In the common case, kinst emulates a traced instruction by copying it to
a trampoline, where it is followed by a jump back to the original code,
and pointing the interrupted thread's %rip at the trampoline. In
particular, the trampoline is executed with the same CPU context as the
original instruction, so if interrupts are enabled at the point where
the probe fires, they will be enabled when the trampoline is
subsequently executed.

It can happen that an interrupt is raised while a thread is executing a
kinst trampoline. In that case, it is possible that the interrupt
handler will trigger a kinst probe, so we must ensure that the thread
does not recurse and overwrite its trampoline before it is finished
executing the original contents, otherwise an attempt to trace code
called from interrupt handlers can crash the kernel.

To that end, add a per-CPU trampoline, used when the probe fired with
interrupts disabled. Note that this is not quite complete since it does
not handle the possibility of kinst probes firing while executing an NMI
handler.

Also ensure that we do not trace instructions which set IF, since in
that case it is not clear which trampoline (the per-thread trampoline or
the per-CPU trampoline) we should use, and since such instructions are
rare.

Reported and tested by: Domagoj Stolfa
Reviewed by: christos
Fixes: f0bc4ed144fc ("kinst: Initial revision")
Differential Revision: https://reviews.freebsd.org/D37619

show more ...


# 778b7437 08-Dec-2022 Mark Johnston <markj@FreeBSD.org>

kinst: Make the provider ops table const

No functional change intended.


Revision tags: release/12.4.0
# a72edfea 15-Nov-2022 Mateusz Guzik <mjg@FreeBSD.org>

dtrace: avoid kinst warn when not used

Reviewed by: markj
Sponsored by: Rubicon Communications, LLC ("Netgate")


# f0bc4ed1 11-Oct-2022 Christos Margiolis <christos@FreeBSD.org>

kinst: Initial revision

This is a new DTrace provider which allows arbitrary kernel instructions
to be traced. Currently it is implemented only for amd64.

kinst probes are created on demand by lib

kinst: Initial revision

This is a new DTrace provider which allows arbitrary kernel instructions
to be traced. Currently it is implemented only for amd64.

kinst probes are created on demand by libdtrace, and there is a probe
for each kernel instruction. Probes are named
kinst:<module>:<function>:<offset>, where "offset" is the offset of the
target instruction relative to the beginning of the function. Omitting
"offset" causes all instructions in the function to be traced.

kinst works similarly to FBT in that it places a breakpoint on the
target instruction and hooks into the kernel breakpoint handler.
Because kinst has to be able to trace arbitrary instructions, it does
not emulate most of them in software but rather causes the traced thread
to execute a copy of the instruction before returning to the original
code.

The provider is quite low-level and as-is will be useful mostly only to
kernel developers. However, it provides a great deal of visibility into
kernel code execution and could be used as a building block for
higher-level tooling which can in some sense translate between C sources
and generated machine code. In particular, the "regs" variable recently
added to D allows the CPU's register file to be accessed from kinst
probes.

kinst is experimental and should not be used on production systems for
now.

In collaboration with: markj
Sponsored by: Google, Inc. (GSoC 2022)
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36851

show more ...