Project ideas for a Linux kernel module

Probably the most useful thing you could do would be take any Android device (or iOS device with the bootrom exploit) and rebase the patches for it on mainline, clean them up and get them merged into mainline Linux. Same goes for any other device not supported in mainline really, but Android devices are almost always like this.

Along those lines, look at all the dkms modules in any Linux distro and try to talk to the module authors about mainlining, do the work needed if they agree to it.

Also, I have some ideas for Linux kernel things I noticed are needed in my branches of linux.git. I doubt I'll work on them any time soon, so feel free to use the ideas/code I've left in the branches.

  cleanups/bluetooth-magic-numbers
  cleanups/debian
  features/dmesg-richness
  features/hwmon-streaming
  features/in-kernel-cross-fs-copy
  features/lvm-raid-discard
  features/runtime-syscall-lookup
  features/sys-class-storage
  features/tmpfs-o-discard
  features/tmpfs-user-xattr
  features/usbip-flexibility

https://github.com/pabs3/linux/branches/all

Not directly related to your question, but check out the KernelNewbies community and also some of the FOSS internship programs, especially GSoC and LKMP offer paid internships to work on the Linux kernel.

https://kernelnewbies.org/ https://github.com/fossjobs/fossjobs/wiki/resources#internsh...

If you're in for a wild ride, you could try to take some reasonably current Android phone and get enough of the manufacturer's changes to the Linux kernel upstream to run generic Linux on it.

There are a lot of patches that are purely Android-specific and won't ever make it to upstream Linux, but others, like the drivers for flash chips and USB? These could definitely be submitted upstream.

Samsung for example uploads their FOSS dumps to [1].

First thing I'd do is to get u-boot working as a fourth-stage bootloader so you don't have to wrestle with ODIN or fastboot every time you rebuild your kernel. That alone should be a decent sized university project.

[1] https://opensource.samsung.com/uploadList?menuItem=mobile&cl...

[2] https://en.wikipedia.org/wiki/Booting_process_of_Android_dev...

I have recently been looking into getting a 12" Apple Macbook for on the road. The 12" Macbooks were small 12" Intel laptops produced between 2015 and 2017. They can boot Linux, but many devices are not functioning.

They are great little machines, though a bit underpowered (even when they were new) so running MacOS is not a great experience. Decent Linux support should give these devices a second live.

Most devices should be able to work, as they are all standard components. My suspicion is that we are mostly lacking device trees and maybe some SMC work.

I expect the circuit diagrams for this laptop to be floating around the web somewhere (otherwise shoot Louis Rossman an email), so reverse-engineering the SMC should be doable, and a great low level/embedded challenge.

Id love a way for userspace applications to leverage the MMUs memory protection to trigger user code. Let me give you an example: Lets say I have large block of memory that is encrypted. I want to random access this memory, but i don't want to decrypt the entire memory before i start using it. I may have worker threads that start decrypting the data for me, but i don't want to wait for them. Ideally, id like to set a memory protection flag on all pages that are still encrypted, and then if any access is made of these pages, a callback will trigger that lets you decrypt the block and remove the flag from the page, only when accessed.

This could be used for things like user space memory mapping of networked memory, where memory is retrieved from a remote computer when accessed. This would make it possible to transparently implement userspace large scale shared memory systems in a very elegant way. Good luck with what ever you decide to do!

Writing or modifying an existing driver for something like an I2S DAC would suit you, I think.

You'd have to figure out phandle support for the I2C configuration channel, fire up I2S streaming by enabling it in the kernel and piping audio to the DAC, then playing it into some speakers.

Could expand it by adding some filtering. Many DACs have filter banks that you can populate with coefficients via I2C.

There's some decent kernel module resources and examples in this repo if this is something you're brand new to:

https://github.com/Johannes4Linux/Linux_Driver_Tutorial

If you have any interest or experience in cybersecurity and have considered doing that professionally, my company is hiring and likely will be all year. We probably have a use for a new SWE on the embedded side. Email me at my username at Gmail.

Given Linux now allows bits written in Rust, I think a port-to-Rust project may be interesting. There's probably some place on the internet where the Rust minded are discussing what are the most interesting projects in this space (I have no idea, sorry). It could make a cool review on the differences between both implementations, wrt complexity, safety, LOC, compile time, etc.

Perhaps you can work on the new promising Shortest Path Bridging (SPB) in the Linux kernel that has not been very popular as it should be [1],[2],[3].

[1] 802.1Q-2018 - IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks:

https://ieeexplore.ieee.org/document/8403927

[2] Provider Backbone Bridging for Linux:

https://github.com/openss7/pbbr

[3] Are there inherent problems with 802.1aq preventing wider adoption?

https://www.reddit.com/r/networking/comments/8gez0r/are_ther...

One of the early projects I worked to teach myself networking was Port Knocking[1]. Think of it like designing a calling bell for your servers where they can smartly understanding who is doing the "knocking" on their ports. Writing it as a linux kernel module, with the low level cryptographic functions would be a great learning tool imo. I also wrote about my progress here[2] when I attempted this about 7-8 years ago.

[1]:https://en.wikipedia.org/wiki/Port_knocking [2]:https://rnikhil.com/2016/12/12/port-knocking-python.html

write a backdoor :) A kernel module that drops the user into a root shell if they call an obscure kernel functionality with a secret value in some registers.

This should be somewhat easy to start and self-contained. If you want, you can easily extend it if you want things to become more fancy. E.g., hiding the secret constant. Implementing a challenge response protocol, limiting access to other global state (hardware dongle? ip address?) and so on.

There is an effort to write linux drivers for peripherals in Pine Ox64 https://wiki.pine64.org/wiki/Ox64, the chip(BL808) documentation is not that great. But would be a good exercise to write some drivers.

Some ideas:

* You can select a board with not fully supported peripheral Examples RISC-V or Loongson boards with incomplete or missing drivers.

* or create a higher abstractions over the SPI for a A/D or D/A or pwm chip. The module offers a /dev/ file that hides the SPI communication or the motor position and encoding...

One of my pet peeves is that the Linux SPI driver framework has a very transactional API. You can read/write N bytes to a bus at a time.

Some SPI devices can stream out lots of data on the bus. I’m looking at you ADCs.

It’d be nice to have a stream style API for that. Not sure which Linux framework is best suited for that. Maybe IIO but something on those lines might be fun to explore.

One project I made for myself was to to wtite a kernel module that could control the led backlight of my laptop keyboard.

I had to first reverse engineer the windows utility that was written in c# and found out that it used wmi commands. After reading the kernel code for a while I realized there where already some code that implemented HP WMI commands.

Using that as a foundation it was quite easy to write my own kernel module that could change the led colors. Then I tried to integrate it with the linux kernel's led API. Since the LEDs where RGB it was a little different to integrate but I managed to find some examples in some playstation joystick driver code.

This project was a lot of fun, but I would say that you should be careful not to break your hardware. I have broken devices even from the user space by pushing it beyond it's limits.

Not a project idea, but you might get a little inspiration from Asahi Lina. They're developing the linux kernel for M1 Macs and often stream it. https://github.com/asahilina

I always wanted a module that writes string to syslog. Sometimes it's hard to tell where certain things start, especially during init, so I would add string to kernel log, do the thing, add another string marking the end of my thing and then in the syslog I would find that first string and what's after that is what I need.

Write a simple USB driver for interacting with some arduino widget. I'm talking actual USB not serial emulation. For instance, when you plug in some microcontroller/arduino with a small LCD screen you can `echo Hello World > /dev/my_lcd_screen` and it will appear.

Maybe it would be a nice project to see if you could get Zig working in the Linux kernel?

You mention communication protocols. There was a recent article here about a tool bridging an ipv6 only Linux box to the ipv4 world using LD_PRELOAD. A kernel module could trap the calls in a more clean way. https://news.ycombinator.com/item?id=35773554

Just write i2c or SPI for a baremetal firmware, not esp32 nor stm. linux is way overkill for small devices.

Can I get '/dev/chatgpt'? That would make scripting easier.

Being able to mount compressed archives as a file system could be interesting.

If you have any interest, HardMAC 802.15.4 driver support in the kernel is poor. I’m learning this the hard way, right now.

If you're willing to forgo Linux, there is a lot of work / interest in Zephyr.