# WireGuard/wireguard-linux: the GitHub mirror that documents the kernel

> WireGuard/wireguard-linux presents itself on GitHub as a mirror only, pointing at https://git.zx2c4.com/wireguard-linux for the official tree, while its README, top-level entries and Makefile belong to a Linux kernel build. For anyone deciding where to read or build WireGuard's kernel code, that split settles the question before any download starts.

**WireGuard/wireguard-linux** — Mirror only. Official repository is at https://git.zx2c4.com/wireguard-linux

- Repository: https://github.com/WireGuard/wireguard-linux
- Website: https://www.wireguard.com
- Stars: 2,047 · Forks: 310
- Language: C
- License: NOASSERTION
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/wireguard-wireguard-linux

## This GitHub mirror defers to git.zx2c4.com for the real tree

GitHub describes this repository as a mirror and points to https://git.zx2c4.com/wireguard-linux as the official repository. The stable branch contains a Linux kernel tree, including the WireGuard implementation. The mirror is useful for browsing and linking to code; consult the canonical host and the exact revision when checking development history or building.

## Nine named roles, none of them a VPN operator

Before it explains anything, the README defines the Linux kernel as the core of any Linux operating system, in charge of hardware, system resources and the fundamental services for all other software. It then sorts readers into 9 roles and hands each one a short list of pointers. A new kernel developer gets Documentation/process/development-process.rst and Documentation/process/submitting-patches.rst. A security expert gets Documentation/security/lsm-development.rst, Documentation/process/cve.rst and Documentation/userspace-api/seccomp_filter.rst, which is hardening and vulnerability work. A distribution maintainer gets Documentation/admin-guide/module-signing.rst and Documentation/admin-guide/tainted-kernels.rst. Not one of the 9 roles is a VPN or tunnel operator, and no path in any list names WireGuard, a tunnel interface or a key file. The ninth entry is the odd one out: a block headed CRITICAL instructs any LLM or AI coding assistant to read Documentation/process/coding-assistants.rst before contributing, where licensing, attribution and the Developer Certificate of Origin are set out.

## Find the implementation under drivers/net/wireguard

The top level resembles a Linux kernel tree because it is one. The absence of a top-level WireGuard directory does not mean the source is missing: look under drivers/net/wireguard/. Its Makefile lists the objects that make up wireguard.o, including device, peer, send, receive, noise and netlink components, with the build controlled by CONFIG_WIREGUARD. Inspect the files at the revision you plan to audit or build.

## Where to get a kernel and how the documented build starts

The project gives no install script and no package name. It points you at the kernel sources instead. Only 4 lines in the quick start cover the whole path: report a bug through Documentation/admin-guide/reporting-issues.rst, get the latest kernel from https://kernel.org, build the kernel by way of Documentation/admin-guide/quickly-build-trimmed-linux.rst, and join the community on the mailing lists at https://lore.kernel.org/. For documentation there is a target you can run and a place to read the result online:

```bash
make help
make htmldocs
```

`make help` is the one literal command in the repository's own build files, and the top Makefile points developers at it with the note that it shows the list of typical targets. `make htmldocs` builds the documentation set, which the README also says can be read at https://www.kernel.org/doc/html/latest/. Beyond those two targets and the trimmed-build document, the project spells out no configure, compile or install command, so treat any step-by-step build sequence found elsewhere as unconfirmed until it lines up with that document.

## The top Makefile refuses any GNU Make below 4.0

The top Makefile is where a build refuses to start. Its first guard is a hard version floor:

```make
$(error GNU Make >= 4.0 is required. Your Make version is $(MAKE_VERSION))
```

A build run with an older Make stops on that message before any object file is compiled, and the line prints $(MAKE_VERSION) exactly as detected on your machine. A second guard blocks a naming habit that would otherwise work by accident:

```make
$(error targets prefixed with '__' are only for internal use)
```

Behind those guards sits the default target, PHONY := __all, which runs when the command line names nothing at all, followed by a recursive build whose environment is pinned before it descends:

```make
MAKEFLAGS += -rR
unexport LC_ALL
LC_COLLATE=C
LC_NUMERIC=C
export LC_COLLATE
```

Those lines switch off make's built-in rules and variables, which the file justifies as increasing performance and avoiding hard-to-debug behaviour, and they force collation and numeric formatting to C so a build cannot change under a different locale. LC_ALL is deliberately not exported. The Makefile governs the kernel build; the WireGuard implementation itself is in drivers/net/wireguard/.

## Four Makefile variables and one mascot name identify the source

Identity sits in 4 variables and 1 name at the top of that Makefile:

```make
VERSION = 7
PATCHLEVEL = 3
SUBLEVEL = 0
EXTRAVERSION = -rc5
NAME = Baby Opossum Posse
```

Those lines place the tree at series 7, patchlevel 3, sublevel 0, candidate five, under a name that follows the kernel's own naming habit. It is worth pausing on that: a repository named for a VPN carries the kernel's own version identity here, with no second version string for the tunnel anywhere beside it. Below the variables the file states the recursive build contract: sub-Makefiles should only ever modify files in their own directory, and the cases that need global effects are pulled out ahead of the descent into an explicit prepare rule. The toolchain dotfiles agree with the languages on offer, with .pylintrc for the Python under scripts/, .clippy.toml and .rustfmt.toml for the Rust under rust/, and .cocciconfig for the semantic patching kernel contributors use.

## Configuration guidance and the kernel implementation

The kernel's top-level README is not a WireGuard operator guide, but the source tree contains the implementation under drivers/net/wireguard/. For setup, the official quick start at https://www.wireguard.com/quickstart/ explains creating an interface, generating keys and configuring peers with wg. Use the wg and wg-quick manual pages for details, and protect private keys. A code audit should examine the relevant source and exact revision, rather than infer protocol behaviour from the top-level README.

## Choosing a source and configuring WireGuard

The project identifies https://git.zx2c4.com/wireguard-linux as its official repository; the GitHub tree is a mirror. Both can be used to inspect the nested WireGuard code, while the canonical host is the reference for the project's tree. For a build, verify the exact kernel revision, its toolchain requirements and CONFIG_WIREGUARD. For deployment, follow the official WireGuard quick start and the documentation for the distribution or kernel you actually run.

## Conclusion

The GitHub repository is a mirror of the Linux tree named by the project. Its WireGuard implementation is under drivers/net/wireguard/, even though the top-level README describes the kernel as a whole. Use the official WireGuard quick start for interface and key configuration, and consult the canonical repository for the authoritative tree. Before building, check the requirements and version in the exact revision you intend to use.

## FAQ

### Where is the official WireGuard Linux source if this GitHub repository is only a mirror?

The project's own description names https://git.zx2c4.com/wireguard-linux as the official repository, and the homepage it carries is https://www.wireguard.com. The mirror suits reading, searching and linking into code, and the project points development elsewhere.

### Does the WireGuard/wireguard-linux repository on GitHub contain the WireGuard kernel module source?

Yes. The kernel implementation is nested under drivers/net/wireguard/. Its Makefile builds wireguard.o from files including device, peer, send, receive and noise components when CONFIG_WIREGUARD is enabled.

### What version does the top Makefile in this tree declare?

The top Makefile identifies the Linux kernel version for the checked-out revision, not a separate WireGuard release. Branches change, so inspect that file at the exact commit you use.

### How do I start building what this repository describes?

The README sends builders to https://kernel.org for the latest kernel and to Documentation/admin-guide/quickly-build-trimmed-linux.rst for the build steps, and the top Makefile names `make help` as the way to list typical targets. Documentation itself is produced with `make htmldocs`, and no configure or install command is spelled out.

### Does the README document WireGuard configuration keys or a tunnel interface?

The top-level kernel README is a general kernel guide. For interface, peer and key configuration, see the official WireGuard quick start and the wg and wg-quick manual pages.

## Sources

- [Issues](https://github.com/WireGuard/wireguard-linux/issues)
- [Project website](https://www.wireguard.com)
- [README](https://github.com/WireGuard/wireguard-linux/blob/stable/README.md)
- [WireGuard/wireguard-linux on GitHub](https://github.com/WireGuard/wireguard-linux)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wireguard-wireguard-linux