Investigate kernel error call stacks



retsnoop is BPF-based tool that is meant to help debugging kernel issues. It allows to capture call stacks of kernel functions that return errors (NULL or -Exxx) and emits every such detected call stack, along with the captured results.

It's output in a default brief form looks like this:

$ sudo retsnoop -p bpf -ss
Receiving data...
                             entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                             do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
           24us [-EINVAL]    __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                             . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)
                             __do_sys_bpf+0x5ca                        (kernel/bpf/syscall.c:4438:9)
                             . bpf_btf_load                            (kernel/bpf/syscall.c:3818:9)
           21us [-EINVAL]    btf_new_fd+0x213                          (kernel/bpf/btf.c:5639:8)
                             . btf_parse                               (kernel/bpf/btf.c:4246:8)
                             . btf_parse_type_sec                      (kernel/bpf/btf.c:4009:5)
            0us [-EINVAL]    btf_check_all_metas+0x5                   (kernel/bpf/btf.c:3856:1)

                             entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                             do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
            2us [-EINVAL]    __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                             . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)

                             entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                             do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
           46us [-ENOMEM]    __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                             . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)
                             __do_sys_bpf+0x359                        (kernel/bpf/syscall.c:4375:9)
                             . map_create                              (kernel/bpf/syscall.c:828:8)
                             . find_and_alloc_map                      (kernel/bpf/syscall.c:122:8)
           41us [-ENOMEM]    array_map_alloc+0x1eb                     (kernel/bpf/arraymap.c:150:16)
                             . bpf_array_alloc_percpu                  (kernel/bpf/arraymap.c:39:6)
           16us [NULL]       bpf_map_alloc_percpu+0x3f                 (kernel/bpf/syscall.c:436:2)
                             . set_active_memcg                        (include/linux/sched/mm.h:315:6)
                             . preempt_count                           (arch/x86/include/asm/preempt.h:27:9)
           14us [NULL]       __alloc_percpu_gfp+0x5                    (mm/percpu.c:1894:9)
            0us [NULL]       pcpu_alloc+0x5                            (mm/percpu.c:1679:1)

Here three different error call stacks were captured and inline symbolization was performed. Functions with '. ' prefix are inlined functions, detected by addr2line (see below).

The same set of errors in verbose mode looks like this:

$ sudo retsnoop -p bpf -ss -v
Using vmlinux image at /lib/modules/5.12.0-rc2-00442-g87d77e59d1eb/build/vmlinux.
Discovered 46315 available kprobes!
Found 1016 attachable functions in total.
Skipped 44660 functions in total.
Function '__ia32_sys_bpf' is marked as an entry point.
Function '__x64_sys_bpf' is marked as an entry point.
Total 2032 BPF programs attached successfully!
Receiving data...
                              ffffffff81c0007c entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                              ffffffff81bee6dd do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
           63us [-EINVAL]     ffffffff8116de95 __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                                               . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)
                             ~ffffffffa1ac4057 bpf_trampoline_6442464085_1+0x57
                              ffffffff8116c6ca __do_sys_bpf+0x5ca                        (kernel/bpf/syscall.c:4438:9)
                                               . bpf_btf_load                            (kernel/bpf/syscall.c:3818:9)
                             ~ffffffff81195c45 btf_new_fd+0x5
                             ~ffffffffa2ce2057 bpf_trampoline_6442474345_1+0x57
           48us [-EINVAL]     ffffffff81195e53 btf_new_fd+0x213                          (kernel/bpf/btf.c:5639:8)
                                               . btf_parse                               (kernel/bpf/btf.c:4246:8)
                                               . btf_parse_type_sec                      (kernel/bpf/btf.c:4009:5)
            6us [-EINVAL]     ffffffff8118ede5 btf_check_all_metas+0x5                   (kernel/bpf/btf.c:3856:1)
                             ~ffffffffa2cfe080 bpf_trampoline_6442474383_1+0x80
                             ~ffffffffa0966e53 bpf_prog_814c04020ce2e2d5_fexit1+0x463
                             ~ffffffff81155491 bpf_get_stack_raw_tp+0x51
                             ~ffffffffa0966e53 bpf_prog_814c04020ce2e2d5_fexit1+0x463

                              ffffffff81c0007c entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                              ffffffff81bee6dd do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
            7us [-EINVAL]     ffffffff8116de95 __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                                               . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)
                             ~ffffffffa1ac4080 bpf_trampoline_6442464085_1+0x80
                             ~ffffffffa03cc5fb bpf_prog_814c04020ce2e2d5_fexit1+0x463
                             ~ffffffff81155491 bpf_get_stack_raw_tp+0x51
                             ~ffffffffa03cc5fb bpf_prog_814c04020ce2e2d5_fexit1+0x463

                              ffffffff81c0007c entry_SYSCALL_64_after_hwframe+0x44       (arch/x86/entry/entry_64.S:112:0)
                              ffffffff81bee6dd do_syscall_64+0x2d                        (arch/x86/entry/common.c:46:12)
           83us [-ENOMEM]     ffffffff8116de95 __x64_sys_bpf+0x5                         (kernel/bpf/syscall.c:4351:1)
                                               . __se_sys_bpf                            (kernel/bpf/syscall.c:4351:1)
                             ~ffffffffa1ac4057 bpf_trampoline_6442464085_1+0x57
                              ffffffff8116c459 __do_sys_bpf+0x359                        (kernel/bpf/syscall.c:4375:9)
                                               . map_create                              (kernel/bpf/syscall.c:828:8)
                                               . find_and_alloc_map                      (kernel/bpf/syscall.c:122:8)
                             ~ffffffff81188145 array_map_alloc+0x5
                             ~ffffffffa2928057 bpf_trampoline_6442473861_1+0x57
           67us [-ENOMEM]     ffffffff8118832b array_map_alloc+0x1eb                     (kernel/bpf/arraymap.c:150:16)
                                               . bpf_array_alloc_percpu                  (kernel/bpf/arraymap.c:39:6)
                             ~ffffffff8116a3d5 bpf_map_alloc_percpu+0x5
                             ~ffffffffa26a406d bpf_trampoline_6442473048_1+0x6d
           26us [NULL]        ffffffff8116a40f bpf_map_alloc_percpu+0x3f                 (kernel/bpf/syscall.c:436:2)
                                               . set_active_memcg                        (include/linux/sched/mm.h:315:6)
                                               . preempt_count                           (arch/x86/include/asm/preempt.h:27:9)
           22us [NULL]        ffffffff811e4815 __alloc_percpu_gfp+0x5                    (mm/percpu.c:1894:9)
                             ~ffffffffa1ca4065 bpf_trampoline_6442477050_1+0x65
            3us [NULL]        ffffffff811e4035 pcpu_alloc+0x5                            (mm/percpu.c:1679:1)
                             ~ffffffffa1ea6096 bpf_trampoline_6442477052_1+0x96
                             ~ffffffffa0ba2513 bpf_prog_22cf752688d52e2b_fexit4+0x463
                             ~ffffffff81155491 bpf_get_stack_raw_tp+0x51
                             ~ffffffffa0ba2513 bpf_prog_22cf752688d52e2b_fexit4+0x463

Those function calls with ~ in front are filtered out, as they correspond to BPF trampoline and BPF programs, which most probably are coming from retsnoop's own instrumentation. You should be able to ignore them most of the time.

Entry, allow, and deny globs

Retsnoop allows to specify functions of interest with glob expressions:

  • entry globs, for functions that would trigger tracking of call stacks (e.g., *_sys_bpf to trace bpf() syscall); any other function will be ignored, unless it is called, directly or indirectly, from one of the entry functions;
  • allow globs, for functions that will be traced and whose return results would be captured on errors; allowed functions don't trigger the tracing itself, but they are tracked as part of entry function's call stacks;
  • deny globs, for functions that should never be traced (e.g., if they are too low-level to trace safely).

To specify entry/allow/deny globs, use -e/-a/-d options, like so:

$ sudo retsnoop -e '*_sys_bpf' -a '*bpf*' -d 'migrate*' -d 'rcu*'

Use cases

Additionally, retsnoop comes with so-called use cases, which are predefined sets of entry, allow, and deny globs. One or more of those use cases can be specified:

$ sudo retsnoop -c bpf

Either use case or at least one entry glob that matches at least one function has to be specified. Entry functions (those that match entry globs) are automatically enlisted as allowed functions.

Currently only bpf use case is defined.

Filtering by process ID (PID)

It is possible to only trace kernel stacks within the context of specified PID:

$ sudo retsnoop -c bpf -p 123

In the future, retsnoop might support auto-spawning of the process in perf fashion like this:

$ sudo retsnoop -c bpf -- ./my_app arg1 arg2

Call stack symbolization

Retsnoop is "hosting" fast Rust-based addr2line utility internally, which it can use to perform more extensive stack trace symbolizations, including source code level information (file path and line number and position) and inline function calls. To use them, specify either -s for line number info only or -ss for both line info and inline fuctions. With high rate of errors, extra symbolization might be too prohibitive, so please try with and without extra symbolization. Retsnoop performs a simple function name + offset resolution using /proc/kallsyms-based unconditionally.

When extended symbolization is requested, resnoop is expected to find kernel image (vmlinux) in one of standard locations (e.g., /boot/vmlinux-$(uname -r)). It is possible to specify kernel image location explicitly with -k option.


retsnoop embeds addr2line inside to perform additional stack symbolization, including file/line information and inline function calls. retsnoop runs addr2line in a separate process with two pipes for stdin/stdout communication. To allow this mode of operation without additional complexities of setting up pseudo-terminals, addr2line is modified to forcefully flush its stdout output after each symbolized address. Until [PR] ( is applied upstream, patch can be applied on top of the latest master branch. But for convenience, custom-built and stripped addr2line (x86-64 architecture only) is already checked in in this repository under tools/.

Kernel and environment dependencies

Retsnoop is using some of the more recent BPF features (BTF, fentry/fexit BPF program types, etc), so will require sufficiently recent kernel version. It's on our TODO list to determine minimum upstream kernel version that retsnoop supports.

Building retsnoop from source

See pre-built versions of retsnoop for x86-64 (amd64) architecture in Releases section.

It's also straightforward to build retsnoop from sources. Most of retsnoop's dependencies are already included:

  • libbpf is checkout as a submodule, build and statically linked automatically by retsnoop's Makefile;
  • the only runtime libraries (beyond libc) is libelf and zlib, you'll also need develop versions of them to compile libbpf;
  • retsnoop pre-packages x86-64 versions of necessary tooling (addr2line and bpftool) required during the build;
  • the largest external depenency is Clang compiler with support for bpf target. Try to use at least Clang 11+, but Clang 10 might be able to work.

Once dependencies are satisfied, the rest is simple:

$ make -C src

You'll get retsnoop binary under src/ folder. You can copy it to a production server and run it. There are no extra files that need to be distributed.

  • Add functions defined in compile unit(s) to the list of globs

    Add functions defined in compile unit(s) to the list of globs

    By prefixing ':' before the name of a compile unit, all functions defined in the compile unit will be added to the specified list of globs. For example, giving '-a :path/to/XXX.c', all functions defined in XXX.c will be added to the allow list.

    opened by ThinkerYzu1 10
  • Fix arm64 build

    Fix arm64 build

    Currently retsnoop doesn't work in my arm64 machine as it reports uname -a as aarch64,

    Also update the instruction pointer accessor to use some BTF goodness, as arm uses user_pt_regs instead of pt_regs.

    BTW, thanks for this tool! It's incredibly useful and works great! ❤️ Will throw away all my custom bpftrace scripts to do half of what this tool does. Would send you a #thanks if I could :)

    opened by javierhonduco 3
  • retsnoop: build addr2line from the source.

    retsnoop: build addr2line from the source.

    Use the source of the implementation of addr2line in the examples/ directory of gimli-rs to build a binary to keep tools/addr2line always update-to-date.

    Signed-off-by: Thinker Lee [email protected]

    opened by ThinkerYzu1 1
  • mass_attacher: switch to bpf_program__insns() for BPF program cloning

    mass_attacher: switch to bpf_program__insns() for BPF program cloning

    Drop deprecated bpf_program__set_prep() API in favor of bpf_program__insns() and bpf_program__insn_cnt() to implement fentry/fexit BPF program cloning for mass-attachment.

    Signed-off-by: Andrii Nakryiko [email protected]

    opened by anakryiko 1
  • Add explicit target to sidecar/Cargo.toml

    Add explicit target to sidecar/Cargo.toml

    cargo read-manifest needs this, and this is used by Fedora's Rust macros to generate the list of dependencies.

    Signed-off-by: Michel Alexandre Salim [email protected]

    opened by michel-slm 0
  • retsnoop: sidecar accepts verbs in requests

    retsnoop: sidecar accepts verbs in requests

    The sidecar is going to provide various features. To support that, every request have to be prefixed with a verb to designate what function it requests.

    This change is on the top of PR3.

    opened by ThinkerYzu1 0
  • Consult one question about cards_found

    Consult one question about cards_found

    Hello, I capture one trace with this kind of: entry_SYSCALL_64_after_hwframe+0x65 do_syscall_64+0x5b __x64_sys_sendto+0x24 __sys_sendto+0xee 27us [-EAGAIN] sock_sendmsg+0x5 cards_found.85860+0x1a4 sock_sendmsg+0x3e 24us [-EAGAIN] tcp_sendmsg+0x5 cards_found.85860+0x1ac tcp_sendmsg+0x27 3us [-EAGAIN] tcp_sendmsg_locked+0x5 cards_found.85860+0x1c6 cards_found.85860+0x125 cards_found.85860+0x1fb cards_found.85860+0x19e cards_found.85860+0x19e

    But there is something that I cannot find from vmlinux :( How to check the cards_found.85860?

    Thanks, Mark

    opened by mzhan017 1
  • v0.8(May 28, 2022)

    Few pretty big usability improvements.

    1. More flexible and compact stack trace formatting. Retsnoop is now trying to determine the minimal correct size of each output column so as to keep the stack trace alignment but also using minimal amount of horizontal space.
    2. This same logic is reused for formatting LBR stacks, which also allows to have from and to branches emitted "horizontally", instead of one after the other as before. This improves the comprehension significantly.
    3. Retsnoop now recognizes symbol LBR flags aliases, allowing much easier tuning of what kind of LBR data to capture. E.g., --lbr=any_return will capture only returns from functions, allowing to see further into unknown sequence of kernel function calls. This is very useful when trying to discover what's going on without knowing particular area of the kernel you are trying to debug. By default retsnoop is effectively using --lbr=any.
    4. --lbr-max-count N was added to limit number of last useful LBR records. It's not always necessary to see all 32 of them, last 5 or some might be more than enough.

    With all the above changes, here's an example of one captured error with LBR stack traces included. Retsnoop is run as:

    $ sudo ./retsnoop -e '*sys_bpf' -a ':kernel/bpf/syscall.c' -n simfail --lbr=any_return --lbr-max-count=5

    Failure is simulated with simfail:

    $ sudo ./simfail bpf-bad-map-lookup-value

    And here's the result:

    09:24:54.846 PID 336615 (simfail):
                        entry_SYSCALL_64_after_hwframe+0x44  (arch/x86/entry/entry_64.S:112:0)
                        do_syscall_64+0x2d                   (arch/x86/entry/common.c:46:12)
        34us [-ENOENT]  __x64_sys_bpf+0x1c                   (kernel/bpf/syscall.c:4749:1)
        27us [-ENOENT]  __sys_bpf+0x1a42                     (kernel/bpf/syscall.c:4632:9)
                        . map_lookup_elem                    (kernel/bpf/syscall.c:1113:5)
    !    7us [-ENOENT]  bpf_map_copy_value
    [#07] migrate_disable+0x3c       (kernel/sched/core.c:1755:1)      ->  bpf_map_copy_value+0x31       (kernel/bpf/syscall.c:241:2)
    [#07]                                                                  . bpf_disable_instrumentation (include/linux/bpf.h:1453:2)
    [#06] array_map_lookup_elem+0x24 (kernel/bpf/arraymap.c:168:1)     ->  bpf_map_copy_value+0x1ed      (kernel/bpf/syscall.c:269:10)
    [#05] rcu_read_unlock_strict+0x5 (kernel/rcu/tree_plugin.h:797:1)  ->  bpf_map_copy_value+0x18c      (include/linux/rcupdate.h:724:2)
    [#04] migrate_enable+0x59        (kernel/sched/core.c:1783:1)      ->  bpf_map_copy_value+0x9e       (kernel/bpf/syscall.c:288:2)
    [#04]                                                                  . maybe_wait_bpf_programs     (kernel/bpf/syscall.c:170:49)
    [#03] bpf_map_copy_value+0xba    (kernel/bpf/syscall.c:291:1)      ->  __kretprobe_trampoline+0x0
    Source code(tar.gz)
    Source code(zip)
    retsnoop(3.37 MB)
  • v0.7(Apr 13, 2022)

    Two major features:

    1. Extremely fast multi-kprobe is used if kernel supports it (automatically, need 5.18+ kernel). This speeds up attachment and especially detachment time immensely. There is no way to understate this. It's seconds and potentially minutes (if attaching to a lot of functions) against a couple milliseconds with multi-kprobe.
    2. Error filter support. Use -x ENOMEM to report stacks that return -ENOMEM. Use -X ENOMEM to skip stacks that report -ENOMEM. NULL is an error, so -x NULL and -X NULL is also supported. You can combine multiple -x and -X options together. -X takes precedence (i.e., if some error is disabled, enabling it with -x won't help).
    Source code(tar.gz)
    Source code(zip)
    retsnoop(3.36 MB)
  • v0.6(Nov 29, 2021)

    Lots of quality of life improvements:

    • Ability to specify functions by their source code locations.Use the following syntax in -e, -a and -d: :fs/btrfs/*.c'.
    • Default to safer kprobe mode by default. Can be overriden with -F argument.
    • Symbolization with line info and inline functions is now on by default, no more need to specify -ss. If vmlinux image can't be located, fall backs to -s none (-sn), meaning no extra symbolization beyond using /proc/kallsyms.
    • Dry run mode added (--dry-run) which will do everything but load and attach BPF programs. Very useful to figure out what retsnoop will try to trace without risking affecting the system.
    • -V (--version) now prints retsnoop version.
    Source code(tar.gz)
    Source code(zip)
    retsnoop(2.02 MB)
  • v0.5.1(Nov 1, 2021)

  • v0.5(Sep 29, 2021)

    A huge milestone for retsnoop: LBR capturing!

    When kernel supports capturing LBR entries from BPF kprobe/fexit function, it will capture such LBR records and emit relevant them after the captured stack trace. This allows to trace back inside the last failed/traced function, including logic inside the inlined functions. This allows to see where exactly inside potentially large function the error happened. Use --lbr flag to enable this feature. If kernel doesn't support this feature, retsnoop will report this with a warning, visible in verbose mode (-v).

    Relevant kernel feature was added by Song Liu in Linux kernel commit 856c02dbce4f ("bpf: Introduce helper bpf_get_branch_snapshot").

    Source code(tar.gz)
    Source code(zip)
    retsnoop(3.13 MB)
  • v0.4.1-alpha(Aug 10, 2021)

  • v0.2-alpha(May 11, 2021)

  • v0.1-alpha(Mar 24, 2021)

Andrii Nakryiko
Andrii Nakryiko
repo to house various LLVM based SIHFT passes for RISCV 32/64 soft error resilience

compas-ft-riscv COMPAS: Compiler-assisted Software-implemented Hardware Fault Tolerance implemented in LLVM passes for the RISC-V backend Repo to hous

EDA@TUM 2 Jan 10, 2022
C++17 & C++ 20 error-handling and utility extensions.

C++ 17 & C++ 20 error-handling and utility extensions. Overview STX is a collection of libraries and utilities designed to make working with C++ easie

Basit Ayantunde 426 Jun 25, 2022
Implementation of mmap system call in xv6

NOTE: we have stopped maintaining the x86 version of xv6, and switched our efforts to the RISC-V version (

Rohit Chaudhari 6 May 18, 2021
A fork of Wraith Cyborg, the Call of Duty: Online Asset Exporter

NOTE: No support is provided for this, it was updated for a friend who works on a CoD OL Mod and it working for him was all that mattered, it is provi

Philip 6 Jan 26, 2022
Phantom Attack: Evading System Call Monitoring

Phantom attack is a collection of attacks that evade Linux system call monitoring. A user mode program does not need any special privileges or capabilities to reliably evade system call monitoring using Phantom attack by exploiting insecure tracing implementations.

Rex Guo 16 Jun 1, 2022
An efficient and versatile system call hook mechanism

Zpoline: hooking system calls without pain Zpoline is a novel system call hook mechanism that offers the following advantages. 100 times faster than p

null 88 May 26, 2022
Add a new system call.

Linux kernel ============ There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML an

SamFu1113 1 Jan 11, 2022
Xmodelconverter - A converter for xmodel & xanim files for Call of Duty

xmodelconverter A converter for xmodel & xanim files for Call of Duty. It converts xmodel & xanim files back into xmodel_export and xanim_export text

Richard 7 May 13, 2022
Macro magic for declaring/calling Objective-C APIs from C11 or C++. Preloads selectors, chooses the correct objc_msgSend to call per method/platform.

OC - Easily Declare/Invoke Objective-C APIs from C11 or C++11 Usage // Call class and instance methods: NSWindow* const nswindow = oc_cls(NSWindow,new

Garett Bass 46 May 31, 2022
A tool to convert Call of Duty XBIN/EXPORT files to and from each other.

exportxbin exportxbin is an enhanced version of export2bin included in the Call of Duty: Black Ops III Mod Tools. Its main goal is to provide users wi

Philip 3 Jan 22, 2022
Loads a signed kernel driver which allows you to map any driver to kernel mode without any traces of the signed / mapped driver.

CosMapper Loads a signed kernel driver (signed with leaked cert) which allows you to map any driver to kernel mode without any traces of the signed /

null 103 Jun 20, 2022
A kernel module to provide /system/xbin/su to Android Kernel (especially to WSA)

WSA-Kernel-SU Intro This is a kernel module to provide /system/xbin/su to Android Kernel (especially to WSA). Only works on 4.17+ kernel. For older ke

LSPosed 123 Jun 15, 2022
NetHunter Kernel for the OnePlus 7 Series based on DragonHeart Kernel

Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel develop

cyberknight777 9 Mar 13, 2022
a unix inspired, non posix compliant micro kernel (more of a monolithic kernel for now though) that i am working on in my spare time

toy-kernel a unix inspired, non posix compliant micro kernel (more of a monolithic kernel for now though) that i am working on in my spare time prereq

czapek 13 Jun 14, 2022
A kernel module that patches Linux kernel "on-the-fly" to skip TASK_RSS_EVENTS_THRESH check in check_sync_rss_stat

split-rss-counting-patch A kernel module that patches Linux kernel "on-the-fly" to skip TASK_RSS_EVENTS_THRESH check in check_sync_rss_stat. Why? Read

Bao-Hiep Le 3 Mar 6, 2022
Pixel 4/XL kernel.

Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel develop

Sultan Alsawaf 73 Apr 28, 2022
PS4 kernel hooking library / payload.

PS4 KHook PS4 KHook is a minimalist kernel hooking payload. It targets 5.05 but it can be used with any firmware (or even non-PS4 systems) with modifi

Specter 43 May 10, 2022
A CAF rebased kernel for Mi 9 & RedMi K20 Pro MIUI 12.5

Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel develop

Stephen Sin 60 Jun 16, 2022
Quick fix to iphone usb tethering with ios14 or higher for Linux kernel lower than 5.10.4

Quick fix to Linux Iphone USB tethering with IOS 14 or higher (Tested with ubuntu 18.04, kernel 5.4.0-65, if you fail in the build, please download yo

null 23 May 6, 2022