netlink interface for ethtool
a project by mkubecek
Updated over 4 years ago. 4 hacker ♥️.

There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started.

The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).

Links:

Join this project

Looking for hackers with the skills:

kernel networking netlink c

This project is part of:

Hack Week 16 Hack Week 17 Hack Week 18 Hack Week 19

Activity

  • over 4 years ago: jiriwiesner left this project.
  • over 6 years ago: dsterba liked this project.
  • over 6 years ago: pvorel liked this project.
  • about 7 years ago: a_faerber liked this project.
  • about 7 years ago: jiriwiesner joined this project.
  • about 7 years ago: jiriwiesner liked this project.
  • about 7 years ago: mkubecek added keyword "kernel" to this project.
  • about 7 years ago: mkubecek added keyword "networking" to this project.
  • about 7 years ago: mkubecek added keyword "netlink" to this project.
  • about 7 years ago: mkubecek added keyword "c" to this project.
  • about 7 years ago: mkubecek started this project.
  • about 7 years ago: mkubecek originated this project.


    • Comments

    • mkubecek
      about 7 years ago by mkubecek | Reply

      I played a bit already, here is a small demo.

    • mkubecek
      about 7 years ago by mkubecek | Reply

      End-of-hackweek status: disappointing, to be honest. Because of a series of P0/P1 bugs, not much time was left to work on the project. The plan was to have 8-10 most common subcommands implemented on both kernel and ethtool side, ready for an RFC submission, and maybe also some work on wireshark dissector. Reality is much less impressive:

      • kernel: basic infrastructure, GET_DRVINFO, GET_SETTINGS and half of SET_SETTINGS
      • ethtool: basic infrastructure, ethtool -i

      Current code can be found in mkubece/ethnl on Github and home:mkubecek:ethnl OBS project. Let's hope we can get to an RFC submission by the end of this week (I would like to have ethtool ( | -s | -i ) working on both sides for that).

    • mkubecek
      over 6 years ago by mkubecek | Reply

      Marked the project for Hackweek 17 but I won't actually have Hackweek 17 in the usual sense due to Netdev conference. Instead, the plan is to dedicate five days (probably five Fridays in near future) to the project.

      Current state: kernel supports GET_DRVINFO, {G,S}ET_SETTINGS and {G,S}ET_PARAMS, dumps for all supported requests and notifications for SETTINGS and PARAMS (DRVINFO is read only by nature so there shouldn't be anything to notify). All of these requests are also supported by ethtool; the code for dumps (use* as device name) and monitoring (use --monitor as first parameter) also exists but the parser needs a bit more work to be presentable.

    • mkubecek
      over 5 years ago by mkubecek | Reply

      Status update just before Hackweek 18.

      Kernel series is almost ready for upstream submission of first part. The main missing part is unified request header and unified processing of it. There may also be some minor issues found in v5 review. Submitting v6 is the primary goal for Hackween 18 but it should only take part of the week (the smaller the better).

      More work needs to be done on userspace ethtool utility which is lagging behind a bit:

      • without EVENT notifications (rejected by upstream), monitor will need "lazy load" of string sets
      • some commands will require rtnetlink or devlink; rethink the context structure and socket handling
      • monitor needs to also listen to and react to rtnetlink and devlink notifications
      • syntax extensions need to be documented in man page
      • new debugging options showing structure of sent/received messages
      • use the same parser to interpret bad attribute offset from extack error/warning messages

    • mkubecek
      almost 5 years ago by mkubecek | Reply

      Status update before Hackweek 19

      After few more review rounds and rewrites, initial part of the kernel series was accepted to net-next tree and reached mainline as part of the 5.6 merge window (so that it's going to appear in v5.6-rc1. What is in mainline at the moment allows netlink based implementation of

      • ethtool
      • ethtool s ...
      • ethtool -P (using rtnetlink)

      and corresponding notifications.

      The userspace ethtool counterpart, however, will need a lot of work to make it ready for upstream submission. As it is highly desirable to have it in ethtool 5.6 release, this is going to be the primary focus at least for the first part of Hackweek 19.

    • mkubecek
      almost 5 years ago by mkubecek | Reply

      Status update after Hackweek 19

      TL;DR: The primary goal was achieved (12 minutes before the end of the week add-emoji ).

      Summary of the Hackweek 19 progress:

      • abstractions for netlink socket and message buffer separated from struct nl_context
      • rework the code generating multiple messages from one set of parameters (for ethtool -s)
      • rework "char bitset" parser (for ethtool -s wol ...)
      • drop bitfield32 helpers and other code no longer used
      • compatibility with existing test suite (make check succeeds now)
      • split some too long patches
      • some bugs fixed
      • lot of style cleanups
      • more comments and better commit messages
      • cover letter
      • current work in progress tracked on github again

      The resulting series has been submitted to upstream.

    Similar Projects

    Officially Become a Kernel Hacker! by m.crivellari

    Description

    My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

    I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

    Maybe this will be a good chance to...

    Goals

    • create my first kernel patch

    Resources

    Achivements

    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

    One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

    For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

    Goal for this Hackweek

    Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

    Resources

    Contributing to Linux Kernel security by pperego

    Description

    A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.

    I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.

    I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller

    Goals

    1. Fix at least 2 security bugs
    2. Create the fuzzing lab and having it running

    The story so far

    • Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
    • Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
    • Day 3: Working on trivial changes after I read this blog post: https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence with the patch preparation and submit process yet.
      • First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
      • Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
    • Day 4: Triaging more issues found by Coverity.
      • The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
      • Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
    • Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.

    • Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.

      I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.

    The patches

    1

    Hacking on sched_ext by flonnegren

    Description

    Sched_ext upstream has some interesting issues open for grabs:

    Goals

    Send patches to sched_ext upstream

    Also set up perfetto to trace some of the example schedulers.

    Resources

    https://github.com/sched-ext/scx

    Create DRM drivers for VESA and EFI framebuffers by tdz

    Description

    We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.

    Goals

    • Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
    • Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.

    Remote control for Adam Audio active monitor speakers by dmach

    Description

    I own a pair of Adam Audio A7V active studio monitor speakers. They have ethernet connectors that allow changing their settings remotely using the A Control software. From Windows :-( I couldn't find any open source alternative for Linux besides AES70.js library.

    Goals

    • Create a command-line tool for controlling the speakers.
    • Python is the language of choice.
    • Implement only a simple tool with the desired functionality rather than a full coverage of AES70 standard.

    TODO

    • ✅ discover the device
    • ❌ get device manufacturer and model
    • ✅ get serial number
    • ✅ get description
    • ✅ set description
    • ✅ set mute
    • ✅ set sleep
    • ✅ set input (XRL (balanced), RCA (unbalanced))
    • ✅ set room adaptation
      • bass (1, 0, -1, -2)
      • desk (0, -1, -2)
      • presence (1, 0, -1)
      • treble (1, 0, -1)
    • ✅ set voicing (Pure, UNR, Ext)
    • ❌ the Ext voicing enables the following extended functionality:
      • gain
      • equalizer bands
      • on/off
      • type
      • freq
      • q
      • gain
    • ❌ udev rules to sleep/wakeup the speakers together with the sound card

    Resources

    • https://www.adam-audio.com/en/a-series/a7v/
    • https://www.adam-audio.com/en/technology/a-control-remote-software/
    • https://github.com/DeutscheSoft/AES70.js
    • https://www.aes.org/publications/standards/search.cfm?docID=101 - paid
    • https://www.aes.org/standards/webinars/AESStandardsWebinarSC0212L20220531.pdf
    • https://ocaalliance.github.io/downloads/AES143%20Network%20track%20NA10%20-%20AES70%20Controller.pdf

    Result

    ESETv2 Emulator / interpreter by m.crivellari

    Description

    ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu. The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.

    This is an example using one of their samples (it prints N Fibonacci numbers):

    .dataSize 0
.code

loadConst 0, r1 # first
loadConst 1, r2 # second

loadConst 1, r14 # loop helper

consoleRead r3

loop:
    jumpEqual end, r3, r15

    add r1, r2, r4
    mov r2, r1
    mov r4, r2

    consoleWrite r1

    sub r3, r14, r3
    jump loop
end:
hlt

    This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.

    Goals

    • create a full interpreter able to run all the available samples provided by ESET.
    • improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)

    Resources

    Achivements

    Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.

    FastFileCheck work by pstivanin

    Description

    FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.

    https://github.com/paolostivanin/FastFileCheck

    Goals

    • Release v1.0.0

    Design overwiew:

    • Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
    • Dedicated consumer thread: manages queue and distributes work to threadpool
    • Worker threads: compute hashes in parallel

    This separation of concerns is efficient because:

    • Directory traversal is I/O bound and works well in a single thread
    • Queue management is centralized, preventing race conditions
    • Hash computation is CPU-intensive and properly parallelized

    Add a machine-readable output to dmidecode by jdelvare

    Description

    There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

    Goals

    Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.

    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

    This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

    This project is free software and you can find it here.

    Goal for this Hackweek

    • Better understand the RISC-V SBI interface.
    • Better understand RISC-V in privileged mode.
    • Have fun.

    Resources

    Results

    The project was a resounding success add-emoji Lots of learning, and the initial target was met.