Ask HN: Project ideas for a Linux kernel module | Hacker News Reader

Ask HN: Project ideas for a Linux kernel module

81 pointsmailey47 comments

Hey HN, I'm currently a senior CS student (graduating in fall), I wanted to align my career with low level/embedded systems and I wanted to focus more on the kernel/firmware side of things.

so to that end, What would be a good idea for a linux kernel module I can work on, something that may get me to interact with any topics involving communication standards/protocols ( i2c, SPI, or JTAG, wireless, BLE).

thank you.

View on HN

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...

Yeah, supporting Android devices in mainline kernel would be really useful also for projects like postmarketOS (https://postmarketos.org/)

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...

This would greatly help projects like postmarketOS. Plenty of old devices that have already been partially ported to pick from: https://wiki.postmarketos.org/wiki/Devices

Having an existing community may also be useful for figuring this stuff out.

Anything that supports the Android ROM scene and that makes their life easier sounds fantastic in my opinion. Please have a go here.

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.

So Elementary OS is one example of Linux that already runs very happily on my 2012 MacBook Air.

Surely most of the required support is there already?

I wasn't talking about the Macbook Air, but rather the 12" Retina Macbook [0].

Also known as the A1534 Macbook8,1 (yes, Apple's naming is always confusing).

https://support.apple.com/kb/SP757?locale=en_US

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!

You could probably do this in userspace now with userfaultfd.

Can't you catch sigsegv since forever?

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.

Proper codec driver would be heavily abstracted though. I2C hidden behind regmap. Regmap mostly hidden behind ALSA kcontrol API. A lot of codec drivers consist mostly of tables of mappings between abstract controls and register locations/values. Not very exciting stuff. Finding an acquirable SoC that doesn't have DAI driver implemented may also be a challenge.

But why not I guess. :)

Camera sensor drivers are a bit less abstracted and many sensors don't have upstream drivers. But there's also a lack of quality documentation for HW in this area, oftentimes... v4l2 API is a bit more approachable than alsa PCM API, IMO. And on advanced SoCs you can pass around video buffers bewteen various v4l2 mem2mem devices to transform/process the data in HW. Drivers for HW acceleration of image or video data processing are seldom exercised in all their features, so there are many bugs there waiting to be squashed, and features to be implemented. It's a deep rabbit hole.

Anywhere is a good place to start.

Let the fella learn.

Thank you, that does sound interesting, and I do have an interest in cybersecurity (just not IT security as in firewalls, incident response ...etc). I saw some interesting stuff being done recently from programming/writing code to emulate a microcontroller/CPU in something like qemu, to power glitching and bypassing protection on some chips to allow accessing serial/debug interface or even some of the mobile baseband reverse engineering/emulation being done by experienced security researchers. but I couldnt tell what kind of experience I would need to have for that sort of job, or where to start, at least I think starting with embedded projects and low level OS-related stuff would someday lead me to that career path.

> 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.

I'll keep this mind, thank you.

We don't do IT cybersecurity. That stuff is boring. :)

Our work is much closer to the metal. There's a big hardware component. Based on what you describe, we have work that I strongly suspect you'd find interesting. Your intuition was correct - low level coding and OS stuff is where all the goods are at.

Shoot me an email at cushychicken@gmail.com and I can tell you about what we do in a bit more detail.

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

You can also get your hands dirty with writing a proxy or a VPN which in my opinion also exposes you to a lot of low level stuff. My other suggestion would be malware reverse engineering but I don't think you are interested in systems/OS based on your post.

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.

What kind of documentation one would normally need for this sort of project? If the documentation are not great or missing something, is there steps that could be taken to figure out the chips functions in order to implement them?

The chip has complete-ish sdk here(https://github.com/bouffalolab/bouffalo_sdk) we use as "documentation". Datasheet and the reference manual are incomplete.

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.

That's cool! Did you publish the module somewhere? Could it be in mainline?

This is kinda funny but I was going to try to get it merged to mainline but then realized there was already a similar patch waiting on review.

This my code, large part of it is based on other HP WMI stuff https://github.com/kuterd/hp_omen_led_controler

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

The voice filters, the cutesy avatars, a little too much for me. I think it's a bit better without audio.

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.

Does following work for you? echo test > /dev/kmsg

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.

I know what you mean, sometimes I wonder how small is really small, what I had in mind when I posted this thread was a project that might help me gain experience in building something related to embedded/IoT devices (routers, phones, low level but not too level that it doesn't have a kernel if that makes sense).

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

I feel `#!/bin/chatgpt` incoming soon

I'm not really a fan of chatgpt-related topics :> lets just say it will take sometime for it, to grow on me.

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

Isn't it what archivemount is for?

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.

What kind of basic minimum hardware I would need to take on a project like this?

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

If you're willing to forgo Linux, but want to be Linux adjacent, maybe look at getting the Linux hda drivers running on FreeBSD linuxkpi; HDMI audio on at least intel would work better with coordination between the audio driver and the video driver; FreeBSD uses Linux drivers for video, but not for audio and the coordination is missed, so the audio driver doesn't know when the video driver has reprogrammed the clocks for a different resolution and you get mistimed audio :(. Alternatively, figure out how to use the coordination hooks in the Linux video driver with the FreeBSD audio driver.

But really, to answer your question; the best thing is to find something that you actually want your computer to do that's feasible, but not possible because there's no kernel module. Then you'll be incentivized to keep going with the project, not just a resume/interview material project.

Reply on news.ycombinator.com