Drink this potion, Linux kernel, and tomorrow you'll wake up with a WireGuard VPN driver The developer of WireGuard has laid the groundwork for plugging his open-source privacy tool directly into the Linux kernel in hope of making secure communications easier to deploy and manage. Jason Donenfeld, creator of WireGuard and the founder of Edge Security, on Tuesday submitted a proposed set of patches to the Linux …
"WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come." - https://www.wireguard.com/
I'm super interested in this project and even been thinking about testing it out at home. Now I'm not a linux expert, or even involved in the kernel development process but I'm pretty sure software needs to be stable to be added to the kernel.
Certinaly the team over at Netgate/pfSense think so >> "It will never be a "high priority feature" until they actually make a proven secure/stable release." - https://forum.netgate.com/topic/132375/installing-wireguard-vpn/5
Jason seems to be overly cautious, I've been running it on my Ubiquity ER-X and Android phone and this thing rocks. In terms of speed and stability, it leaves OpenVPN and the likes far behind.
What stands out most: enabling it doesn't involve any connection at all, zero battery drain. But when it notices you try to reach the configured network, it will pack your packets and send them off.
Since both Linus and Greg are a big fan of WireGuard, chances that it gets merged are the full 100%
The Linux kernel is already heading towards bloat central.
The module mechanism was invented so that you could add functionality without having to include it in the kernel as a compile time option.
The only possible reason for doing this would be if it were needed during system startup, for example if you wanted to network boot through a VPN. This would be problematic, especially as you would have to find some way of loading the certificates or keys before having a filesystem available.
It seems to me that some Linux developers need to remember the design decisions that were made to try to make running Linux easier!
Give that man a cigar.... you've hit the nail on the head!
Many moons ago, I had a ran a Linux VM that was optimised to be a VPN server, literally everything was stripped from it, the total size was 1.2MB (yep you read it!) and could run off a floppy (not that I ever did). These days, you'd be lucky to get away with a 4GB USB stick..
"These days, you'd be lucky to get away with a 4GB USB stick.."
I agree with the sentiment.
Linux can still be efficient if you compile with only needed stuff. Check a base rpi for example. ~4Mb for the kernel.
I checked some kernel devs responses to the WireGuard submission, crypto people specifically are not very happy with current state of the patch. Interesting reading. They too dont want duplicated code or bloat.
Linked from HN comments that published this yesterday.
Seems to me the developer of this code is a bit bolshy and might get slapped down a bit before this patch gets applied. :)
I personally see no problem with crypto stuff in userland. Imagine heartbleed in the Linux kernel.
@Anonymous Coward said: "I had a ran a Linux VM that was optimised to be a VPN server (...) These days, you'd be lucky to get away with a 4GB USB stick."
Let's see how that compares to the actual size of a popular Linux ISO.
Ubuntu desktop: size is 1,953,349,632 bytes. That includes a full GUI (Unity), office suite (LibreOffice), web browser (Firefox), email client (Thunderbird) and all sorts of media players and other odds and ends. If you just want the desktop with web browser, pick minimal install and the other stuff will get left out.
Ubuntu server: is 845,152,256 bytes. That is just over a fifth of the size of the desktop ISO.
For Debian I just have the server net install, but the installed size won't be much different than the above.
FreeBSD (not Linux, but we'll list it anyway) is 2,930,397,184
OpenSuse is 3,917,479,936 bytes, although you don't have to install everything it includes.
Those are the ones I happen to have sitting around. The Ubuntu desktop will boot directly from the ISO so you can try it out without installing it.
If you want to know the install size, then as an example a Debian 9 64 bit server has a Virtual Box VDi size of 1.7 GB. However, that includes a C compiler and a bunch of other extraneous stuff that I use for testing software, so you can probably cut that down somewhat.
It is a module. From the patch:
+config WIREGUARD
+ tristate "WireGuard secure network tunnel"
+ depends on NET && INET
+ select NET_UDP_TUNNEL
+ select DST_CACHE
+ select ZINC
+ default m <------------ compile as a module by default
+ ---help---
+ WireGuard is a secure, fast, and easy to use replacement for IPSec
+ that uses modern cryptography and clever networking tricks. It's
+ designed to be fairly general purpose and abstract enough to fit most
+ use cases, while at the same time remaining extremely simple to
+ configure. See www.wireguard.com for more info.
+
+ It's safe to say Y or M here, as the driver is very lightweight and
+ is only in use when an administrator chooses to add an interface.
+
"The Linux kernel is already heading towards bloat central."
By which criteria do you judge that - binary kernel packages, source tree, occupancy? And what do you mean by 'bloat'?
Growth in the size of the Linux kernel is inevitable over the course of time due to the addition of new features and drivers. However, much of that growth can be countered by compiling your own kernels and omitting all the stuff that you know you don't need. This also reduces the number of sub-systems where things might go wrong and can also reduce the attack surface too. Of course, you need to have a good idea of what you're doing, which brings us to:
"It seems to me that some Linux developers need to remember the design decisions that were made to try to make running Linux easier!"
I can't recall anyone ever claiming that Linux was designed to make running it easier [easier than what?]
But there are two issues here: why should Linux be easy to run and why do you think it isn't easy to run?
Is it wise to make it easier for people who don't know what they're doing, and who don't comprehend the consequences of what they're doing, to do those things? Would it not be a little like allowing anyone, of any age, to drive an automobile without first demonstrating competence?
I could understand the desire to make Linux easier to run if it was just a toy, but it isn't.
The parts that go into the kernel are very small.
Bloat is not a problem as you can tailor the kernel to match whatever you require, and you're not forced to load all possible modules at all times.
Me wants to have as much functionality and drivers as possible.
A big kernel does not equate bloat, the project is big because the drivers are maintained in parallel to the rest of the kernel, you're not forced to load or use everything under the sun.
> The module mechanism was invented so that you could add functionality without having to include it in the kernel as a compile time option.
No, it wasn't. It was added so that the *compiled* modules didn't all need to be loaded into memory at boot time, enabling the core kernel to stay quite small, but allow a single binary build to provide all the drivers necessary for booting on many systems, which is key (for example) to how distributions provide support for the numerous x86 systems with a single installation.
The kernel doesn't provide a stable module ABI, or infact any guarantees about the stability of the module API for use with out of tree drivers. It is strongly recommended that drivers get merged into the kernel source (should they meet the required coding standards and prove acceptable to the kernel developers).
What the kernel developers will do is fix any drivers that use an internal kernel API when it is changed, assuming it's been merged into the kernel source tree. There are also strong promises in place that the kernel/user space API won't change (quickly at least), but that is an orthogonal issue.
It IS a module, the article is written in a bit of confusing fashion. Currently it is an out of tree module, so if you get a Linux distribution you don't get it like you get xfs or drivers for <insert random 15 year old network card>. You have to track down the source and compile it yourself, or find (and trust) someone who has already compiled it for your Linux kernel version.
They are simply putting the module in the tree, so it'll be on equal status with those other drivers, and most Linux distributions will include it by default. It won't actually load unless you make that happen, of course, just like xfs won't load unless you use it or the 15 year old network card driver won't load unless you have that hardware.
From the actual submission:
"This commit aims to be as self-contained as possible, implementing WireGuard as a standalone module not needing much special handling or coordination from the network subsystem."
So it appears to remains a module. Or is this just a module in the kernel and not actually a kernel module?
Exactly. This is incredibly advantageous for a couple of reasons. Firstly, if somebody else changes an in-kernel API that your code uses, they will generally have to update all users of that API. If your module is part of the tree, they will update it - saving you effort and avoiding bit-rot.
Secondly, it significantly increases the likelihood that your code will be integrated into general purpose Linux distributions, as all they have to do is include the modules in the kernel configuration they build. In the case of WireGuard, some distributions are already including it (using DKMS for example), but this will make it even simpler.
I only read the article, and that contains "pouring his open-source privacy tool directly into the Linux kernel".
I see that it will remain a module, but the intention I get from this is that they are trying to make it compiled directly into the kernel. Maybe the article is misleading.
I actually have no problems with it remaining as a module, either official or unofficial, but there are only a very limited number of scenarios I can see where having it actually compiled in the kernel will benefit users or administrators.
"I see that it will remain a module, but the intention I get from this is that they are trying to make it compiled directly into the kernel. Maybe the article is misleading"
A Linux kernel module is a flexible beast which can be treated in several ways:
Once it is in the kernel tree you can choose to:
1. Compile into the kernel, for speed and compactness.
2. Keep alongside for convenience in tinkering.
3. Ignore in favour of something else.
If it is not yet in the main kernel tree then the options are broadly the same, but 1. and 2. are harder and only 3. is the default.
The submission is about moving it into the main kernel tree.
The article is misleading because it appears not to understand this.
“actually have no problems with it remaining as a module, either official or unofficial, but there are only a very limited number of scenarios I can see where having it actually compiled in the kernel will benefit users or administrators.”
Agree - but want to add one circumstance where it would have helped me on a client project in the past. Would not need to compiled on, but if something was official (in tree) module, it could be described as an OS option to be used, not as an external thing to be added. The first would be approved, the second automatically triggered review by the insecurity team, invariably resulting in four or five pages of reasons for considering anything risky - reasons that usually equated to “we didnt think of it therefore it must be bad” .....
I think it's an issue wether it should be in the kernel repository. After all most drivers in there can already be compiled as modules.
I don't think it should be compiled in, however if its compiled in you could potentially make a VPN server/client without a file system. That would be an interresting idea.
Unlike Microsoft Windows, Linux has absolutely no concept of an installable device driver system.
I mean you plug something in and the appropriate driver is fetched based on USB or PCI IDs even if this sometimes takes a minute or fails.
Instead if you wonder where those Gigabytes went it is because you have
* Every possible X server
* A kernel with tweaks and loadable modules for every CPU (and I don't mean those from Intel and AMD), every motherboard and every USB device the kernel ever catered for
* Every timezone
* Every locale
* A really flaky system of boot relying on initrds that seem to get re-build several times per update so now you have hundreds of megabytes in /boot alone and the thing won't boot when these go wrong which they do
That is total bollocks. All those options are picked up or dropped according to choices made at various stages by the distro, kernel build and install options. For example I use Devuan Ascii's AMD64 build with MATE desktop and customised to my PC via a net install. Linux has even been run on smartwatches. Try that with your iOS or Windows 10!
WRONG!
And most of us aren't simple enough to "install everything". ...and if we did, we would understand that we chose to have a large install.
But let's look at that large install. My Slackware if everything were installed would weigh in at 5GB. What does that get us?
The ability to boot the drive in any system given boot sector/super block is present and correct.
Several Office apps
Several Multimedia apps
Several Development apps
Many Games
Various package managers
Various command line utilities
Various web browsers
FTP servers and clients
SSH clients and servers
Web servers
Database servers
Various programming languages
Various compilers
Various shells
Various locale and languages
Various character support tables
True multi-user support
Proper permission system
Etc
Etc
Etc
Etc
...and what does the same 5GB net you in OSx or Windows? Not very much.
And no proper device driver system?
Get real! There is TONS more device support in Linux and 9 times out of 10, it's plug and play.
Just TRY and connect a 15 year old MP3 player to Win7+, ain't happening. Install over 100MB of support software, it's there, but can't talk to the system. Linux? About 180k on support software, reads, writes, and plays just fine.
Having kernel MODULES (device drivers) for damn near every piece of hardware made since 1990something is a huge plus in my book. Shit, my Madcatz Panther XL joystick lost support in XP. Drivers were 3rd party and buggy. Guess what, still 100% supported under Linux.
Go get Ubuntu.
Forget about Linux. It's not for you.
The number of people who are confused about what WG currently is, and what it is trying to be... ouch.
Currently Wireguard is a DKMS module (see https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support for what that is). Basically, it is "out of tree" and every time a new kernel is installed (like when you do a "apt upgrade" etc and a new one comes in), all DKMS based modules have to be recompiled. Usually on *your* computer. Which means, among other things, you need to install gcc and a whole bunch of other packages.
Getting it into the Linux tree means you don't have to do that anymore. **It will STILL be a module**, except it will be part of the kernel sources, and the compilation happens at the distro, not in your computer.
In particular, it is NOT bloating the kernel any more than it currently is, as a DKMS module, for people who do not use it.
Oh and by the way, I've been using it for a couple of months now and it's absolutely wonderful. I've had no problems of any kind -- so read all that faff about "this is not yet complete" as typical open source "under-promise". It definitely "over-delivers", as far as I am concerned.
"good lord; is this not a techie site? "
-------------------------------------------------------------------------------------------
The last time one person could know all science and technology was centuries ago.
The last time someone could know all computer science and information technology was decades ago.
That not everyone knows one or two specific niche facts or procedures does not give you *any* information on their personal level of competence and understanding of computers and related issues.
-----------------------------------------------------------------------------------------
"Oh and by the way, I've been using it for a couple of months now and it's absolutely wonderful. I've had no problems of any kind -- so read all that faff about "this is not yet complete" as typical open source "under-promise". It definitely "over-delivers", as far as I am concerned."
------------------------------------------------------------------------------------------
And here is the shining example of that. You may know a fair bit about linux modules and kernel compilation, but it really doesn't seem like you have a great handle on issues around cryptographic validation and security.
Good cryptography is *hard*. Some new crypto system outside the cryptographic mainstream is not what you want to count on for security.
Flaws in the math, in the algorithms, in the libraries, in the integration of cryptographic methods, in the choices of parameters, in configuration, or protocols - any of these can break security.
It usually takes years of intense study, review, testing, and experience on the part of the broader cryptographic community to establish a reasonable expectation that a new system can deliver real security.
In five years or so this may be worth considering, but flaws and weaknesses have often been unrecognized even longer than that.
Your endorsement of this cryptographic solution puts me in mind of xkcd # 937.
(https://www.xkcd.com/937/)
"In five years or so this may be worth considering"? Really? TLS had padding related issues several more years later, and I won't even bring up heartbleed. The (passive) passage of time does not indicate anything,
Hence why the "4000 lines -- easy to review" point that is being made here.
I am not a cryptographer, but I know enough, thank you. I still say this is pretty darn good, uses the right set of algorithms (I'll admit to being a Dan Bernstein fanboy), and -- while nothing is absolutely certain -- it's a darn sight more trustworthy than a lot of other code.
And from a practical point of view, it's almost trivial to setup compared to those.
> That not everyone knows one or two specific niche facts or procedures does not give you *any* information on their personal level of competence and understanding of computers and related issues.
True.
Except when they try to *say* things like "bloat" and "it should stay a module" and "I sense another smackdown [from Linus Torvalds]", etc.
xkcd 386, since you're so fond of xkcd.
> Some new crypto system outside the cryptographic mainstream is not what you want to count on for security
It's the bloody cryptographic mainstream that got us the Dual EC-DRBG backdoor and God knows how many more things like that. While I still have a lot of respect for NIST, stepping away and looking at independent cryptographers like Dan Bernstein is definitely a good idea.
In any case, Dan's stuff is no longer an outsider -- almost every crypto suite worth its salt (no pun intended) is implementing it. They're not doing it because they're fanboys either; there are solid reasons -- openness (often called "nothing up my sleeve" in crypto), implementation ease, side-channel resistance, etc.
Seems you missed the link in TFA about formal verification of the cryptographic code which is a missing step for pretty much all similar tools out there. The small size here makes it possible to pull that off as FV is not a simple process. Which process I've done for all my software and hardware of the decades.
"The last time one person could know all science and technology was centuries ago."
Oh go on with you. The article is about something called WireGuard. If you don't know what it is, don't comment about it, or Google it and then comment. The person you're responding to is specifically calling out others on their inability to comprehend bloat, external modules, and precompiled modules; particular the difference between using dkms and not.
> The number of people who are confused
Must agree with the surprised title. Some really astonishing lack on understanding about how the linux kernel works, and the significance, or otherwise of a new project managing to get approval from the kernel developers. The nonsense about bloat and assumptions that being in the mainline meant wg would no longer be a module is so misplaced, one wonders whether trolls have pounced on this. Attempted comparisons of particular distros' kernel compilation choices and the kernel development process really read like FUD shill comments. So unlike ElReg commentards, who we expect and hope to be better informed.
This post has been deleted by its author
I get uneasy when someone pushes for tight integration of secure comms: it's such a high-value target. This is potentially someone for NSA&friends to terrify the s**t out of until he smuggles in a backdoor for them.
Anyone know the chap in question? How would he react if someone were to suggest to him what a shame it would be if his nearest-and-dearest were blind and crippled?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
