| Age | Commit message (Collapse) | Author |
|
arm is a little more complicated because it has three cases:
- big-endian data, big-endian instructions
- big-endian data, little-endian instructions
- little-endian data, little-endian instructions
|
|
Step toward making this work on aarch64eb.
|
|
Rename VM_KERNEL_IO_ADDRESS to VM_KERNEL_IO_BASE to match RISC-V
It's less letters, matches other similar variables and will help with
sharing code between the two architectures.
NFCI.
|
|
This was never relevant on FreeBSD and I don't think it is relevant on
NetBSD either. The FreeBSD change to lift this restriction had the
following comment:
r306570 | markj | 2016-10-02 00:35:00 +0000 (Sun, 02 Oct 2016) | 7 lines
Allow tracing of functions prefixed by "__".
This restriction was inherited from upstream but is not relevant on FreeBSD.
Furthermore, it hindered the tracing of locking primitive subroutines.
|
|
Don't module_hold(NULL)! This mistake was introduced in my attempt
to get dtrace working for sdt probes defined in non-builtin modules
like zfs.
|
|
|
|
|
|
|
|
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
|
|
|
|
- Serialize updates to lockstat_enabled, lockstat_dev_enabled, and
lockstat_dtrace_enabled with a new __cpu_simple_lock.
- Use xc_barrier to obviate any need for additional membars in
lockstat_event.
- Use atomic_load/store_* for access that might not be serialized by
lockstat_lock or lockstat_enabled_lock.
|
|
|
|
|
|
|
|
|
|
|
|
Call kmem_free() with size of data being freed.
|
|
|
|
when unloading the ktrace module on MIPS.
|
|
FreeBSD, with NetBSD-specific changes largely based on aarch64 dtrace
support. Working well enough for system call tracing.
|
|
The code is identical to i386's one.
|
|
|
|
Fix evbarm-aarch64 build.
|
|
|
|
(assuming the machine has a separate statclock() which almost all don't).
|
|
Currently x86_patch_window_open is a big problem, because it is a perfect
function to inject/modify executable code with ROP.
- Remove x86_patch_window_open(), along with its x86_patch_window_close()
counterpart.
- Introduce a read-only link-set of hotpatch descriptor structures,
which reference a maximum of two read-only hotpatch sources.
- Modify x86_hotpatch() to open a window and call the new
x86_hotpatch_apply() function in a hard-coded manner.
- Modify x86_hotpatch() to take a name and a selector, and have
x86_hotpatch_apply() resolve the descriptor from the name and the
source from the selector, before hotpatching.
- Move the error handling in a separate x86_hotpatch_cleanup() function,
that gets called after we closed the window.
The resulting implementation is a bit complex and non-obvious. But it
gains the following properties: the code executed in the hotpatch window
is strictly hard-coded (no callback and no possibility to execute your own
code in the window) and the pointers this code accesses are strictly
read-only (no possibility to forge pointers to hotpatch an area that was
not designated as hotpatchable at compile-time, and no possibility to
choose what bytes to write other than the maximum of two read-only
templates that were designated as valid for the given destination at
compile-time).
With current CPUs this slightly improves a situation that is already
pretty bad by definition on x86. Assuming CET however, this change closes
a big hole and is kinda great.
The only ~problem there is, is that dtrace-fbt tries to hotpatch random
places with random bytes, and there is just no way to make it safe.
However dtrace is only in a module, that is rarely used and never compiled
into the kernel, so it's not a big problem; add a shitty & vulnerable
independent hotpatch window in it, and leave big XXXs. It looks like fbt
is going to collapse soon anyway.
|
|
This way there's no dependency on ddb.
|
|
`Toxic' means dtrace forbids D scripts from even attempting to read
or write at them.
Previously we considered [0, VM_MIN_KERNEL_ADDRESS) toxic, but
VM_MIN_KERNEL_ADDRESS is only the minimum address of the kernel map;
the direct-mapped region lies below it, and with PMAP_MAP_POOLPAGE we
allocate virtual pages for pool backing directly from physical pages
through the direct-mapped region. Also, this did not consider I/O
mappings to be toxic, which they probably should be.
Instead, treat:
[0, AARCH64_KSEG_START)
and
[VM_KERNEL_IO_ADDRESS, 0xfff...ff)
as toxic. (The upper bound for 0xfff...ff ought to be inclusive, not
exclusive, but I think we'll need another mechanism for expressing
that to dtrace!)
|
|
|
|
Implement dtrace_getarg and dtrace_getreg while here.
|
|
|
|
aarch64 fbt_invop doesn't actually use the argument, but it would
make more sense for it to be the return value and/or first argument
register. Certainly it's not `eax'!
|
|
|
|
|
|
reloads were inverted.
|
|
so we cannot assert for interrupts disabled here.
Should fix PR kern/54603: kernel panic when running dtruss
|
|
PR kern/54397: Panic when loading a DTrace module whilst DTrace is running
|
|
|
|
the direct map may be mapped below "VM_MIN_KERNEL_ADDRESS".
|
|
Register cmajor 252 for fbt and 253 for sdt.
Previously the major number was picked randomly and it causes conflicts
with preallocated values for different devices.
|
|
|
|
ASSERT() is enabled ifdef DEBUG, not DIAGNOSTIC.
|
|
|
|
|
|
|
|
|
|
|
|
Rever changes to upstream files and replace them with additional -Wno-
compiler argument flags.
Tested with base LLVM.
Requested by <chuq>
|
|
Mark arguments to dtrace_probe_lookup() with __UNCONST().
The proper fix constifying it causes pollution of const in too many files.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
|
|
Constify char* types when initialized with liternals.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
|