Some remotely exploitable Linux kernel WiFi vulnerabilities (opens in new tab)

> Many will cry about that performance hit (including me) because for over a decade our computers have gotten faster marginally, but our software has gotten slower and bloatier at an increasingly rapid pace.

We're talking about network stacks and network drivers, not web browsers. Migrating the network stack from the kernel to a user-land process is not going to measurably slow down web browsers, especially on modern systems with gigabytes of RAM, multiple cores, IOMMUs and whatnots.

> These are memory bugs, so the introduction of Rust into the kernel could help us here potentially, no need for an architectural revolution.

That would require rewriting the network stack and network drivers in Rust (driver code is much more likely to have bugs than the rest of the kernel) for this to be effective, otherwise you'll still have a lot of C code in the network path. I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change when drivers were removed from the kernel (can't find the publication about it right now) and they only required reasonably small changes when porting these to user-land, there were not rewritten from scratch.

But this is not just about memory safety, Rust code can still be vulnerable in many other ways (memory leaks, unsafe blocks, wrong assumptions, incorrect algorithm implementation, buggy/compromised toolchains...). Code running inside the trusted computing base of a system is a liability, enforcing privilege separation and principle of least authority reduces it.

A faster network is going to have a marginal effect on software getting slower. There are a lot of factors at play: network speed, cpu power, local caches, etc. The speed of the network driver is one factor among many and I'd be surprised if were the most common bottleneck.

The operators of websites that derive most of their revenue from advertising are going to run their sites at whatever level users will tolerate. Where network drivers are faster they'll either cram in more ad tracking, or won't bother optimizing their existing trackers. If users stop accessing sites because they're too slow to load, operators will either cut down on ad tracking, or more likely, put some effort into optimizing the performance of their ad trackers.

Rust is itself something of an architectural revolution. I believe network drivers in userspace is already a thing, and eBPF may also have a role here. All of this is worth exploring. This is what progress in Linux looks like.

> You can barely navigate the web now with a new low end computer...

You can barely navigate the web now with almost any computer. I have a high-end laptop and opening a few tabs from various sites on the Internet will cause the CPU usage and fan speed to spike. Just for a few tabs! Obviously not all sites do this, but the web has become a framework of advertising monstrosity and I can barely navigate and consume much of today's web content without enabling Reader Mode.

Well, you can navigate the web with older low end computers if you're running the full suite of blockers (NoScript & UBlock on Firefox seems to work pretty well), but that means many sites don't work unless you selectively allow certain scripts to work by fiddling with NoScript permissions and selective blocking some elements with Ublock. HTML + CSS sites are no problem, however.

Regarding the first point. If I understand correctly you say that there is an inevitable performance hit when not running in kernel mode. But is that really so?

How do the micro kernel folks get around this? Are they paying the syscall toll between kernel components?

1) For this very reason, it doesn't make sense to optimize low-level components from the OS down to the hardware anymore, and hasn't for over a decade, if an improved user experience is your goal.

The short-term effect may be a slight improvement, but it's a treadmill and the next wave of web crapware will more than nullify it.

If a microkernel architecture with worse performance got established on all mainstream devices, the experience would be worse in the short term but in the medium term, the crapware would have to adapt so that it again becomes just barely usable as it is today.

The problem is that the short-term gains create an incentive for users to buy/use the marginally faster hardware or kernel, which then forces everyone else to follow suit.

> Many will cry about that performance hit (including me).

Ok, we could make it optional, i.e. additional security for those who wish it (on top of other things we could do, like the things you mentioned but which aren't a panacea too).

This is driver software, not relevant. Rust isn't a magic spell to be thrown out there when traditional solutions work quite well. The old reasons for hard kernel/userland separation are far less reasonable now.

For performance you want to reduce context switches between processes including the kernel. With kernel bypass you do everything in one process in the user space, but you are also losing out on features like sharing hardware resources between processes. With general user space drivers you will gain additional context switches. There are also ways to reduce the cost of those context switches though, like IO-uring that Linux recently got.

indeed, but afaik these more or less depend on dedicating a cpu-thread to the software-thread because a cache eviction would completely wreck the performance

Worse, IP package sizes didn't grow at all. So it would require 200 000 context switches per second if you don't want to add code bundling packets kernel-side and dispatching them a-la Nagle's algorithm. This is both error-prone and adds latency. Even worse, trampolines and other mitigations make it so switches clear CPU cache.

The trick is to not copy the data, but to pass pages around.

It's the opposite: In the last decade networking connection speeds have plateaued. In the 90s we had 100M ethernet, in the 00's 1G ethernet, in the 2010's 10G ethernet, and it stuck there for a long time. We had much much less CPU cycles available per packet when 1G came, for example.

I did not anticipate a Hacker News discussion about a remotely exploitable Linux kernel WiFi vulnerability requiring some network benchmarks on an unusual network stack architecture, but I'll oblige:

This publication (http://www.minix3.org/docs/jorrit-herder/asci06.pdf) claims that MINIX3 could saturate a 1 Gb/s Ethernet link with an user-space network stack, with separate processes for the stack and the driver, on a rusty 32-bit micro-kernel that can't do SMP. In 2006.

This is more of a disparaging analogy than a law.

Note that the Tanenbaum-Torvalds debate was in 1992, over thirty years ago. The security of computer systems might have improved since then, but the fallout of security issues has massively increased. Managing your bank accounts wirelessly on the Internet from anywhere in the world with a thin, battery-powered device that fits inside your pocket was a pipe dream (and no one could've possibly imagined that an Internet-ready smart toaster could compromise it and steal your money on your accounts).

> Be the change you want to see in the world.

I have made dozens of commits to MINIX3, including a brand-new ISO 9660 file system implementation (https://github.com/Stichting-MINIX-Research-Foundation/minix...).

I have made more than a hundred commits to SerenityOS (https://github.com/SerenityOS/serenity/commits?author=boricj).

Just because I deplore the general state of security in mainstream operating systems doesn't mean that I demand that someone else does something about it for free.

I'm not paid to fix security bugs in the Linux kernel, do you expect me to fix these myself for free just because you want to? No one is entitled to my own free time spent hacking on random stuff.

Current everyday networking has tens-of-microseconds latency[1] and on 2018 era CPUs the context switch overhead seems to be 1-2.5 microseconds[2]. So in benchmark and specialized use cases, context switch overhead would be measurable but many orders of magntude away from relevant when talking about communication over the internet.

[1] https://blog.cloudflare.com/how-to-achieve-low-latency/ - 30-45 microseconds on plain 10G ethernet - faster ethernet probably wouldn't improve much on this

[2] https://eli.thegreenplace.net/2018/measuring-context-switchi...

It's not a hack. Virtual address spaces and process isolation were built exactly for misbehaving code.

You can choose sys-net to be a disposable during the install. It's not the default. You can also make it a disposable manually: https://www.qubes-os.org/doc/disposable-customization/#using...

Beware that your WiFi password will be forgotten every VM reboot (but there is a workaround on the forums).

It's possible, but I believe the design is such that sys-net is untrusted, so an exploit there is no more risk than any other use of an unencrypted connection on the network.

But it sure looks like it was a wise idea to spend the resources on isolating network hardware!

Yeah the fact that the kernel has changes like this with such minimal testing is the reason why we see regressions in these kinds of bugs all too often.

> Edit: Looks like GCC removed the warning because it was unreliable. Clang and MSVC seem to be in better shape. https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html

That is an odd position when -Wstringop-overflow also highly depends on the optimizer (and will frequently generate false positives!) but not only remains in GCC but is enabled by default (even without any -Wall/-Wextra).

Things like this are why its pays to compile your project with as many compilers as possible (as well as static analysis tools).

It seems like you're right. I misunderstood something. That's worrying.

ArchLinux seems to also have it patched in 6.0.1-arch2-1 though[0].

[0] https://security.archlinux.org/ASA-202210-2/generate

> The stable release with these fixes will probably be 5.19.16.

Updating my own comment (too late to edit), that release is now out with the fixes. The full set of stable releases with these fixes is: 6.0.2, 5.19.16, 5.15.74, 5.10.148, and 5.4.218 (source: https://lwn.net/Articles/911272/).

I think Fedora 37 beta already use 5.19.15, the stable release in few days afaik.

As long as the vulnerable changes weren't backported to it (I hope they weren't).

> > anybody who uses WiFi

It's worse than that - android kernels process beacon frames even if wifi is disabled.

So you should be worried about this if you have an android 11/12 phone, even if you don't use wifi.

Linux desktop/laptop users should be worried if they have wifi enabled, even if not connected to a network.

You obviously cannot rewrite things in another language overnight. But I do wish that the industry saw this as an emergency rather than something ranging from "well, we will get to it when we get to it" to "ugh, I'm tired of these people talking about memory safety - don't you know that you can write correct C programs?"

The linux kernel in particular is perhaps the single most important piece of software on the planet. And we vulns like this all the time. Hundreds per year. And there's billions more lines of C and C++ out there handling all sorts of untrusted input.

The path off C and C++ is complicated as shit. Interop with Rust is messy and there aren't effective tools for automatic translation. Carbon is barely a language at this point (they don't even have a compiler) and doesn't yet provide safety. The story for the other alternative languages isn't any better. But I really wish the industry was throwing billions at this across dozens of major companies and open source organizations.

I mostly agree, but I think I would have read the comment differently. I've seen C++ people have a strong distaste towards Rust for various reasons and don't exactly care too much about the "memory safety" part. Which is... unfortunate. So while it might be "beating a dead horse", the horse isn't even dead.

>Not to mention the performance and memory use will be worse.

How much?

Faster adoption

Raise awarness