silk-guardian and the case for a USB-triggered kill switch in the kernel

A kernel module rather than a script, and why that matters

Silk Guardian is described as an anti-forensic LKM kill-switch that waits for a change on the USB ports and then deletes selected files and powers the computer off. The LKM detail is the whole design.

A loadable kernel module runs inside the kernel with no userspace dependency, which the feature list states plainly as no dependencies. There is no daemon to install, no service to start, and no window during which a running process could be inspected or a log read before the reaction happens. The project guide describes it as a remake of usbkill as a Linux kernel driver, made for fun and to learn, and credits the many contributors since.

The repository is correspondingly small. The top level holds a Makefile, config.h, dkms.conf, silk.c, a LICENSE file and the project documentation, so the entire implementation is one C file plus its configuration header. The primary language is C, as a kernel module has to be.

The trade-off of running inside the kernel is that the module shares the kernel's privileges and the kernel's fate. A mistake in the trigger logic takes the machine down, and the module must match the running kernel exactly.

Building and loading it takes two commands

The build is a standard out-of-tree kernel module. You need the linux-headers package matching your kernel, and the project gives the install command for it:

sudo apt-get install linux-headers

Then the module is compiled and inserted:

make
sudo insmod silk.ko

The Makefile is the conventional kbuild skeleton. It declares obj-m += silk.o, derives KERNELVER from uname -r, points KERNELDIR at /lib/modules/$(KERNELVER)/build, and the default target runs make -C $(KERNELDIR) M=$(PWD). There is also a clean target and an install target that copies the module into place and runs depmod -a.

What a user should expect from those commands is a compiled silk.ko in the source directory and a module loaded into the running kernel, with no output beyond the usual insmod confirmation. There is no configuration step, no service file and nothing to enable at boot, which is exactly what an ad-hoc tool looks like and also what makes it easy to forget it is loaded.

The config.h file at the repository root is where the behaviour is presumably tuned, since it is the only configuration artifact in the tree.

A kernel update silently disables the module

The most operationally important line in the project guide is the warning about recompilation: Silk Guardian needs to be recompiled and re-enabled as a Linux module every time there is a kernel update, otherwise it stops working.

That is a property of out-of-tree modules rather than a bug, and it has a security consequence worth spelling out. After a routine unattended security update, the machine reboots with a new kernel and the module is gone. Nothing announces this. The kill switch simply stops being there, and the person relying on it has no signal that the protection has lapsed.

The project solves this with DKMS, Dynamic Kernel Module Support, a program whose stated purpose is to automate that chore. The package installs first:

sudo apt install dkms

Then the repository is cloned into /usr/src under the name silk-guardian-1.0, which is the directory naming DKMS expects for the module and version:

cd /usr/src
sudo git clone https://github.com/NateBrune/silk-guardian silk-guardian-1.0

The module is registered with DKMS and made to load at startup:

sudo dkms add silk-guardian/1.0
sudo dkms build silk-guardian/1.0
sudo dkms install silk-guardian/1.0
echo "silk" | sudo tee /etc/modules-load.d/silk-guardian.conf

The last line writes the module name into a file under /etc/modules-load.d/ so the module loads automatically on startup. A dkms.conf file sits at the repository root for the DKMS registration to read.

Verification after a reboot is two commands, one for DKMS status and one to check the loaded modules list:

sudo dkms status
lsmod | grep silk

If the second command returns nothing, the module is not loaded and the protection is not in place.

The three situations the project describes it as built for

The project gives three reasons to want this behaviour, and each implies a different threat model.

The first is a physical seizure scenario. The text notes that police and other aggressors commonly use a mouse jiggler to keep the screensaver and sleep mode from activating, which tells you the intended moment is someone reaching for the machine while it is still powered. The second is that you do not want someone retrieving documents via USB, or installing malware or backdoors through a USB port. The third is improving the security of a full-disk-encrypted home or corporate server, with a Raspberry Pi given as the example, which is the case where unattended remote hardware makes sense.

A tip in the same section proposes attaching a USB key to your wrist with a cord, inserting it into the computer and loading the module. If the machine is stolen, the USB is removed and the computer shuts down immediately. That is a physical tamper switch implemented with the trigger the module already watches for.

The important warning that follows is that you must use partial disk encryption. Without it, an intruder can still access the hard drive. The module deletes files and powers the machine down, but it does not encrypt anything, so the protection it provides is complementary to disk encryption rather than a substitute for it.

Any USB activity triggers it, because whitelisting is still on the list

The feature list is short: shutdown the computer when there is USB activity, secure deletion of incriminating files before shutdown, no dependencies, and difficult to detect.

The to-do list is where the important limitation sits. It includes the ability to whitelist USB devices, removing files before shutdown, and removing the userspace dependency upon shutdown. The changelog adds detail on the last two. Version 1.5 was updated to use shred and remove files on shutdown, and version 2.0 was updated to use the notifier interface, which is the kernel mechanism for receiving device event notifications.

So the current state is that secure deletion happens through shred and the notifier interface carries the events, while whitelisting remains a wish rather than a feature. There is no way to tell the module that a particular USB device is fine.

That has a direct operational consequence. On a desktop with a keyboard, a mouse on USB, a webcam and a phone charger, any of those events can trigger the reaction, so the machine becomes unusable the moment anything is plugged in. On a headless server, where the trigger is meant to matter, the risk of accidental triggering is lower. The absence of whitelisting is the single most consequential gap in the current code.

Wired into DKMS with a version number of 1.0 in the examples

The DKMS registration commands use the identifier silk-guardian/1.0, and the clone directory is expected to be named silk-guardian-1.0. That version string is the DKMS convention of module name and version, and it is worth noticing that it does not obviously track the changelog numbering of the project, where 1.0 was the initial release and 2.0 is the notifier interface update.

The distinction does not have to be a problem. DKMS treats the version as a key for rebuild and install state, and the number in the commands is simply what the maintainer's instructions use. But it means an operator following the guide verbatim should use the same silk-guardian/1.0 pair rather than assuming 2.0 applies, and if the dkms.conf file at the repository root declares a different version, the add step would need to match that instead.

The Makefile also has an install target that runs modules_install and depmod -a, which is the manual path to getting a module into /lib/modules so that the modules-load.d entry resolves. Using DKMS and using make install are two different routes to the same goal, and the guide only walks through the DKMS one.

A small MIT project with a checklist culture and a rewrite history

The project is MIT licensed and lives in a single C file with a Makefile and a DKMS configuration. There are no GitHub releases, so the version to follow is the master branch, and the last push to the repository was on 2026-10-07.

The changelog shows a project that has been rebuilt rather than continuously extended: 1.0 as the initial release, 1.5 moving to shred for secure deletion, and 2.0 moving to the notifier interface. Each of those is a change in how the module observes or acts, which is the kind of change that matters most in kernel code.

The community framing is explicit, with a to-do list that uses checkmark icons for items already handled, and a line acknowledging the community contributions that moved the project along. Contact details are given for email, Keybase and Twitter.

The MIT licence is permissive and has no particular obligation attached to how the module is used, which raises a question the licence itself does not answer: the module deletes files irreversibly by design, and a permissive licence places the responsibility for that squarely on the operator. There is no warranty that the deletion targets the right files or that the trigger will not fire at the wrong moment.

Editorial conclusion

silk-guardian suits someone who already uses full disk encryption, understands that the module destroys data by design, and wants a trigger that fires inside the kernel rather than in userspace, including the tethered USB key arrangement where removing the key shuts the machine down. It does not suit a general-purpose laptop, because the module has no device whitelist, so any USB event triggers it, and it does not suit anyone who needs the machine to keep running through an unexpected USB plug-in. Before installing it, enable partial disk encryption as the project warns, and decide whether the DKMS route is worth it, since a plain insmod module stops working after every kernel update while a DKMS registration survives it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NateBrune/silk-guardian on GitHub
4. README