GPU drivers supporting native contexts with Mesa support.
Wayland sharing between guest and host. It used to be somewhat sloppy (involved protocol parsing; sommilier & wayland-proxy-virtwl) but recently someone undertook a project to do it properly that may soon bear fruit: https://codeberg.org/drakulix/wl-cross-domain-proxy
A VMM to utilize these features: https://github.com/AsahiLinux/muvm
And a solution which ties these things together: https://git.clan.lol/clan/munix
I wonder if it would be possible to live-migrate apps from one machine running munix to another. You could pause, transfer, and resume the virtual machine.
Greg is pretty blunt about this in the video linked in the article: "If you are not using the latest stable / longterm kernel, your system is insecure" (see 51:40-53:00 in [1]). He also calls out Red Hat explicitly for ending up "off in the weeds" with their fixes.
RHEL as an entire distribution may provide good enough security for most environments. But that is not the same claim as "the RHEL kernel is secure" or "they know exactly which commits are relevant". It is still guesswork plus backports, and you're still running behind upstream fixes (many of which will never get pulled in). It is a comfortable myth.
Source: 10+y long (past) tenure at RH in a team adjacent to the kernel team.
EDIT: also because companies like RH tend to know, and are happy to know, the details of their customers' deployments. Compare the article:
> Always remember, kernel developers:
> - do not know your use case.
> - do not know what code you use.
> - do not want to know any of this.
Even RHEL misses things that don't get announced. This is a big issue for LTS kernels and downstreams, although RHEL does a much better job than most due to the nature of the company/ products.
I don't have tons of examples off hand but Spender and Project Zero have a number of examples like this (not necessarily for RHEL! Just in general where lack of CVE led to downstreams not being patched).
https://googleprojectzero.github.io/0days-in-the-wild/0day-R...
Who is helped by this, for example? https://x.com/grsecurity/status/1486795432202276864
> Always remember, kernel developers: > - do not know your use case. > - do not know what code you use. > - do not want to know any of this.
I just found this part so odd. You don't need to know how users are deploying code to know that a type confusion in an unprivileged system call that leads to full control over the kernel is a vulnerability. If someone has a very strange deployment where that isn't the case, okay, they can choose not to patch.
It's odd for every distro to have to think "is this patch for a vulnerability?" with no insight from upstream on the matter. Thankfully, researchers can go out of their way to get a CVE assigned.
Cool. So social engineering it is. You are your own worst enemy anyways.
There is a difference between a provably secure-by-design system, and a formally proven secure implementation, like Sel4.
https://en.wikipedia.org/wiki/Verve_(operating_system)
However, worse is better on the market, and quality doesn't pay off, hence why such ideas take decades into mainstream.
Right, that was the point - so your suggestion that Qubes is a '100% secure OS' is false.
In addition even without bad actors TLS will prevent random corruption due to flaky infrastructure from breaking the page and even caching those broken assets, preventing a reload from fixing it. TCP/IP alone doesn't sufficiently prevent this.
Why do you allow that RCE in the first place?
And unfortunately, there are plenty of security researchers who are only interested in personal CVE counts, and will try to assign highest priority to a mostly harmless bug.
They just stopped assigning priorities/impact scores to them, because "A simple bugfix for a minor thing for one user could be a major system vulnerability fix for a different user, all depending on how Linux is being used"
(For an example of why having severity rating on CVE is a bad idea, see Redhat's treatment of CVE-2025-68343[1] - they gave "high", score 7. Many security teams in large corps would require a quick patch/kernel upgrade. And yes, this is a null-pointer dereference in a single USB device driver. Even if this is exploitable (which I am not sure about), this driver is _never_ going to be loaded into any our cloud machines, so most of our infra is not affected).
[0] https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
LOL
There's a massive difference between "DoS requiring root" and "I can own you from an unprivileged user with one system call". You can say "but that DoS could have been a privesc! We don't know!" but no one is arguing otherwise? The point is that we do know the impact of some bugs is strictly a superset of other bugs, and when those bugs give control or allow a violation of a defined security boundary, those are security bugs.
This has all been explained to Greg for decades, nothing will change so it's just best to accept the state - I'm glad it's been documented clearly.
Know this - your kernel is not patched unless you run the absolute latest version. CVEs are discouraged, vuln fixes are obfuscated, and you should operate under that knowledge.
Attackers know how to watch the commit log for these hidden fixes btw, it's not that hard.
edit: Years later and I'm still rate limited so I can't reply. @dang can this be fixed? I was rate limited for posting about Go like... years ago.
To the person who replies to me:
> This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
That's not true at all. You can know if you're patched for any software that discloses vulnerabilities by checking if your release is up to date. That is not true of Linux, by policy, hence this entire post by Greg and the talks he's given about suggesting you run rolling releases.
Sorry but it's too annoying to reply further with this rate limiting, so I'll be unable to defend my points.
This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
The reason this has to be emphasized is that all new code runs the risk of regressions, and in a production environment, you hate regressions. Therefore, not only do you not want new features, but you also don't want irrelevant bug fixes. Bug fixes, even security fixes, are not magically free of independent regressions. Therefore a valid incentive exists to minimize backports to production environments. And such a balancing act depends on the careful investigation of the impact of known bugs, one by one.
From the fine blog post:
> For those that are always worried “what if a bugfix causes problems”, they should remember that a fix for a known bug is better than the potential of a fix causing a future problem as future problems, when found, will be fixed then.
A whole lot of users can disagree with this. For good, practical reasons. The expected damage of a known bug may be estimated, while an unknown regression brought in by the fix for the known bug may cause way worse damage.
I basically expect that sort of attack to only be pulled off by a state actor or by a black hat convention for the lolz.
Ads injection is a relatively benign kind of tampering. It could be much more creative and sinister.
Things should be https by default these days. There's zero downside anymore.
Reading a blog post about linux security? Do you actually care if the NSA/FBI/CIA/FDA/USDA or anyone else knows you read this particular blog post?
I could understand this argument if we were talking about a social media site, or something more substantial. But a blog post?
> authenticity
It's a linux security blog post. While it's technically possible for a MITM to get in between an inject false information... about linux security? Is that really a real threat?
> integrity
Maybe a real problem, assuming a malicious MITM is trying to target you. But, I suspect, there are other avenues that'd be more fruitful in that case. Just hoping that someone would visit an http site seems like a far fetched concern.
I think all the other explanations are just double-think. Why? If "bugs are just bugs" is really a true sentiment, why is there a separate disclosure process for security bugs? What does it even mean to classify a bug as a security bug during reporting if it's no different than any other bug report? Why are fixes developed in secret & potential embargoes sometimes invoked? I guess some bugs are more equal than others?
If you know that something is a security issue to your organization, you definitely don't want to paint a target on your back by reporting the bug publicly with an email address <your_name>@<your_org>.com. In the end, it is really actually quite rare (given the size of the code base and the popularity of linux) that a bug has a very wide security impact.
The vast majority of security issues don't affect organizations that are serious about security (yes really, SELinux eliminates or seriously reduces the impact of the vast majority of security bugs).
Also Android uses SELinux and still has lots of kernel exploits. Believing SELinux solves the vast majority of security issues is fallacious, especially since it’s primarily about securing userspace, not the kernel itself .
You can already say that for the majority of the bugs being fixed, and I think that's one of the points: tagging certain bugs as exploitable make it seem like the others aren't. More generally, someone's minor issue might be a major one for someone else, and not just in security. It could be anything the user cares about, data, hardware, energy, time.
Perhaps the real problem is that security is just a view on the bigger picture. Security is important, I'm not saying the opposite, but if it's only an aspect of development, why focus on it in the development logs? Shouldn't it be instead discussed on its own, in separate documents, mailing lists, etc by those who are primarily concerned by it?
However you look at it, the only real justification that’s consistent with observed behaviors is that pointing out security vulnerabilities in the development log helps attackers. That explains why known exploitable bugs are reported differently before hand and described differently after the fact in the commit logs. That wouldn’t happen if “a bug is a bug” was actually a genuinely held position.
And on top of your other concerns, this quoted bit smells an awful lot like 'security through obscurity' to me.
The people we really need to worry about today, state actors, have plenty of manpower available to watch every commit going into the kernel and figure out which ones are correcting an exploitable flaw, and how; and they also have the resources to move quickly to take advantage of them before downstream distros finish their testing and integration of upstream changes into their kernels, and before responsible organizations finish their regression testing and let the kernel updates into their deployments -- especially given that the distro maintainers and sysadmins aren't going to be moving with any urgency to get a kernel containing a security-critical fix rolled out quickly because they don't know they need to because *nobody's warned them*.
Obscuring how fixes are impactful to security isn't a step to avoid helping the bad guys, because they don't need the help. Being loud and clear about them is to help the good guys; to allow them to fast-track (or even skip) testing and deploying fixes or to take more immediate mitigations like disabling vulnerable features pending tested fix rollouts.
https://oss-security.openwall.org/wiki/mailing-lists
The good guys are certainly monitoring these channels already.
I don't know nor follow kernel development well enough to answer these questions. My point was just a general reflection, and admittedly a reformulation of Linus's argument, which I think is genuinely valid.
If you allow me, one could frame this differently though: is the memory leak the symptom or the problem?
It doesn't work. I've looked at the kernel commit log and found vulnerabilities that aren't announced/ marked. Attackers know how to do this. Not announcing is a pure negative.
This isn't true though. Some bugs are not exploitable, some are trivial to exploit. Even if sometimes we'd end up with a DoS that was actually a privesc, how does that make it pointless to label the ones we know are privescs as such?
You can argue "oh no sometimes we mislabeled a DoS" but most of the time you can tell when something is going to be a powerful vuln or not ahead of time, I think this is a red herring to optimize around.
> Essentially every commit would need to be labeled as a cve fix, and then it’s just extra work for nothing.
This isn't true and has never been true for any other project. There are issues with the CVE system, this is not one of them. Note that the Linux kernel is the standout here - we don't have to guess about issues in the CVE system, we observe them all the time. "We need a CVE for every commit" is not one of them.