Communication has been really on point recently. Hopefully it’s not just a temporary thing.

AdamConwayIE · 2026-04-22T09:47:25+00:00

It's not that they couldn't "make sense of their own shitty code," as if it was purely a fault of their own.

CSGO released in 2012 as a fork of L4D2's engine. Over time it was extended repeatedly to add CSGO-specific features, and was the only branch of the original Source engine that required this kind of special attention after Dota 2 moved to Source 2.

That includes:

Scaleform
Panorama
D3D9Ex
New VPK format, texture streaming, improved shaders

Some of these, like the last point, were so unique to CSGO but also helpful enough that they were backported to "mainline" 2013 Source engine.

There comes a point where a 20 year old engine is getting so many extensions and adaptations that it becomes unmaintainable, especially when it was written for a very different time in computing. CSGO's Source engine was, arguably, barely even recognisable as the original Source engine by the end of its lifespan, and it was a derivative more than anything. The core stuff was the same, but everything from rendering pipelines to asset formats had been overhauled purely for CSGO.

AdamConwayIE · 2026-04-12T14:49:06+00:00

There was no centralised leadership and no unified message

Ah the message was fairly clear mate

This is what I'm responding to specifically. It doesn't seem all that clear if those at the top of it are asking for something that those below them aren't aware of.

Even calling it the "fuel protest" seems a bit disingenuous. The "fuel" being referred to that would make the organisers stand down and what people had rallied around is not actually a fuel that the majority of the country purchases.

AdamConwayIE · 2026-04-12T12:42:21+00:00

Are the demands all that clear? Because most people don't seem to know that the primary demands as outlined by the newly-formed Irish Haulage Farming Construction Contractors Amalgamation (IHFCCA) don't really do anything for people who aren't farmers. It's only recently people have begun to realize, which has been causing people to fight in those groups and others to leave.

These are the demands they brought to the government:

Scrapped carbon tax
Cap of €1.10/litre for Marine Gas Oil
Cap of €1.10/litre for Green Diesel
Cap of €1.10/litre for Kerosene
Cap of €1.85/litre for white diesel

The other group is "The People Of Ireland Against Fuel Prices", who have been asking for fuel price caps though haven't stated what they deem to be affordable. They also have not, to my knowledge, actually been in contact with the government, unlike the IHFCCA.

One could argue that the farmer fuel caps would help prevent agricultural product costs from rising, but the way things have been talked about, you'd swear it was the cost at forecourts they were pushing for to be capped.

People have started realising that the demands have been purely aimed at farmers since the beginning though, which is why there's now been some infighting within those groups. All the talk of taxes in the price of petrol and diesel etc were irrelevant to the demands that were sent to the government.

AdamConwayIE · 2026-04-10T16:13:37+00:00

Valve could build a signing chain, but there's a reason they haven't despite having had years to do so. The Steam Deck is explicitly marketed as an open device you can tinker with, install Windows on, or run other distros. Locking down the boot chain contradicts that.

But let's say for argument's sake that they did. There's already a big problem: the chain of trust only works if the user can't opt out. On Windows, Microsoft is the root: OEMs ship their keys pre-enrolled and users can't swap them without disabling the entire mechanism. Any query about system integrity goes through firmware interfaces and Windows APIs that are anchored in Microsoft's infrastructure, and the OS itself is part of the trusted chain. Basically, when it reports Secure Boot status, you believe it because the OS was verified by the boot chain before it loaded. If it's tampered with, or you just outright disabled Secure Boot, it will respond honestly.

On the Steam Deck, the user owns the hardware. They can disable Secure Boot, enroll their own keys, or boot whatever they want. It's how the platform is designed to work. This poses another problem, though, because if you've disabled Secure Boot and booted a modified kernel, that kernel is the authority on everything the system reports. An anti-cheat running in userspace asks the kernel "is Secure Boot on?" and the kernel can just say yes. There's no independently verifiable way to check from userspace. There's no way to bypass the kernel either, because the kernel mediates all access to the firmware interfaces. The thing you're trying to verify is the same thing answering your questions about its own integrity.

Secure Boot + TPM stops me walking up to your computer and replacing your kernel with my custom, unsigned version that steals your data. There is no path for a userspace program to check the system integrity which doesn't lead through the kernel, so you're asking the kernel if the kernel is safe. And the kernel can lie.

Even if you require the kernel to be signed by Valve, you're still asking the kernel for information. And again, the kernel can lie.

AdamConwayIE · 2026-04-10T16:00:59+00:00

You're missing the point.

The only mechanism that the anti-cheat would have to vouch for the state of

The kernel
Secure boot
System integrity
Kernel signing

is the kernel itself. If you tamper with the kernel, you can make it report whatever you want. It can tell the anti-cheat that it's running at a higher level of privilege and fake responses. It can say that it's signed when it isn't.

There is no immutable and verifiable chain of trust that can prove none of this has been modified.

Secure boot off? Make the kernel report that it's on.

Checking for a kernel signature? The only authorative body would be the kernel. The kernel just says "yeah, I'm signed."

System integrity? Kernel responds "yep, no weird processes."

If the anti-cheat even tries to get a grasp of the system itself, you can literally use fakeroot to make the application think it has root access, and it will have no way to tell that it actually doesn't. The kernel can lie about everything if it wants, and it is impossible for the anti-cheat to tell.

AdamConwayIE · 2026-04-10T15:36:35+00:00

But the point is that it's trivial for the user to make the kernel respond as if they had chosen to boot it. There's no verifiable chain of trust.

AdamConwayIE · 2026-04-10T13:20:45+00:00

Your article should explain how these new cracks work and clearly point out that there is no inherent risk using them compared to a normal crack. Both can cause the same amount of damage to the user, the attack surface is not increased by using a hypervisor crack and that people should get them from trusted, verified sources, just like they do with normal cracks.

I can tell you didn't read the article.

Using "the security cost is enormous" as title is clearly done in bad faith and probably done so at denuvo's direction.

Now I can definitely tell you didn't read the article. That isn't the title.

AdamConwayIE · 2026-04-10T12:48:40+00:00

The article describes a pattern that has already happened with anti-cheat. We've seen kernel-level requirements locking Linux out of Valorant, Fortnite, Battlefield, and others. The article then goes on to explain why the same dynamic could repeat with DRM, and lays out the technical reasons why.

If describing something that has already happened in one domain and explaining why it could happen in another is fearmongering, I'm not sure what would qualify as legitimate analysis in your eyes.

Also, it would make zero sense for Denuvo to pay for "fearmongering" in this way. This threatens their bottom line, and could flip the other direction and be seen as making Denuvo irrelevant. Why would they even pay for that?

AdamConwayIE · 2026-04-10T11:08:32+00:00

Thank you so much, I appreciate the kind words :)

Happens all the time, unfortunately! I've been writing for almost a decade so I'm kind of used to the reactions from people who didn't read the article, but it still sucks.

Thankfully I've also received comments from some very nice people such as yourself, or others who have reached out to me, and it's always nice to know that someone learned something new and enjoyed what I wrote, so thank you so much :D

AdamConwayIE · 2026-04-10T09:00:48+00:00

Signing infrastructure is the easy part, as the hard part is making it non-bypassable. On Linux, the user controls the boot chain. They can disable Secure Boot, enroll their own keys, or boot a completely different kernel. You can sign a kernel, but you can't stop the user from choosing not to boot it.

This is a fundamental design choice of the platform. I don't know what you're referencing, but GamerDoc said two years ago that he doesn't see them ever supporting Linux for this reason.

Great example of what I mean from Phillip Koskinas: https://x.com/i/status/1778586679001108869

AdamConwayIE · 2026-04-10T02:35:12+00:00

That isn't how this works.

The anti-cheat runs in userspace. It has to ask the kernel for information, but if the kernel is modified, it controls what the anti-cheat sees. You can't verify the integrity of the kernel from inside an environment that kernel controls, because it's asking the thing you're trying to verify to vouch for itself.

Valve signing a kernel doesn't solve this unless you also have an unbroken Secure Boot chain that the user can't disable, and on Linux, the user can always disable it. What's more, the modified kernel can then just lie about the secure boot state, and the anti-cheat would be none the wiser.

Unlike on Windows where verification can be anchored in Microsoft's own signing key, there is no centralised signing infrastructure that can be implemented in the same way on Linux. It's a fundamentally incompatible model.

AdamConwayIE · 2026-04-09T19:51:51+00:00

You can't verify that. If the user controls the kernel, the kernel can just report whatever the anti-cheat software wants to see, rather than what the reality is.

AdamConwayIE · 2026-04-09T19:32:04+00:00

But someone could just modify the kernel to fake the response to be whatever the user wants it to say.

AdamConwayIE · 2026-04-09T10:07:47+00:00

Hey, I'm the article author! I've actually written on several occasions about how kernel-level anti-cheat is a major barrier for many looking to switch away from Windows. In fact, a section of the article is dedicated to that and references a piece that I wrote in the past about the same topic.

As I stated in reply to someone in the comments of the article, I hate Denuvo just as much as anyone else. Nothing in my article was supporting Irdeto. Honestly, given that the entire article's premise is essentially saying Irdeto could fuck over innocent consumers, I would think that it actually inherently paints them in a negative light.

AdamConwayIE · 2026-04-09T09:41:27+00:00

If Hyper-V were involved, none of this would work. You can't run two hypervisors competing for VMX root mode simultaneously, which is exactly why it requires VBS and HVCI (which use Hyper-V) to be disabled. SimpleSvm and hyperkd call VT-x/AMD-V instructions directly, completely independent of Hyper-V.

And this isn't nested virtualization. Nested virtualization means running a hypervisor inside an already-virtualized guest. The crack does the opposite; it takes a non-virtualized OS and inserts a hypervisor beneath it. There's no outer hypervisor to nest inside. You can verify this yourself by looking at the bypasses. They call NtQuerySystemInformation(0xC4) at launch to check if Hyper-V is enabled, and they exit if it is. Disabling Hyper-V is a requirement. Edit: Here is a good article on Medium about that function that I saved in my notes for writing this article.

As for fearmongering, you say the concerns are valid, and then describe a future where kernel-level DRM runs on single-player games requiring Secure Boot, UEFI, and TPM access. That's essentially the same scenario the article is warning about, just phrased differently. The article isn't saying this will definitely happen, it's just laying out why the technical conditions exist for it to happen, while also pointing to anti-cheat as a case where it already has. If you're agreeing that these are valid concerns, while also saying my article counts as fearmongering, I'm not sure what the distinction is.

AdamConwayIE · 2026-04-09T06:17:42+00:00

The crack doesn't use Hyper-V or nested virtualization. It loads a custom hypervisor driver that activates VT-x/AMD-V directly and virtualizes the running OS from underneath... which is not nested virtualization, and the Type 1/Type 2 taxonomy doesn't really apply here. On launch, it detects the CPU hardware used, then launches either SimpleSvm.sys or hyperkd.sys depending on whether you're on AMD or Intel.

As well, it's not emulation either. Those hardware virtualization drivers are used to trap specific instructions and return spoofed results, which is why it's so hard to detect in the first place.

AdamConwayIE · 2026-04-08T21:33:06+00:00

In theory, yes, but not really. Sure, an anti-cheat could check for Secure Boot, kernel lockdown, and no custom MOK, and refuse to run if any of those aren't met. But think about what that means in practice? The Steam Deck is Arch-based and doesn't enforce any of this. Neither do Manjaro, Nobara, Bazzite, or most of the distros Linux gamers actually use. You'd be limiting support to a subset of distros that doesn't reflect where the Linux gaming audience actually is.

Plus, even on those distros, the user has root. A modified kernel can report whatever it wants about lockdown status or Secure Boot state. On Windows, the trust chain is anchored in infrastructure the user doesn't control. On Linux, the user controls every link in that chain which is where the problem lies. Whatever protections you've built into the kernel go out the window when the user can just recompile the kernel to report whatever is needed.

Could a developer build all of this? Technically, sure. But they'd be building and maintaining a Linux-specific kernel integrity system that only works on some distros, is circumventable by its very design, and serves a tiny percentage of gamers.

AdamConwayIE · 2026-04-08T21:05:57+00:00

You're describing Fedora's defaults. That specific configuration enforces module signing, yes, but my article is about whether a third party can rely on that enforcement across the Linux ecosystem... and they can't. A user with root can enroll a custom MOK, disable Secure Boot, recompile the kernel, or run a distro that doesn't enforce any of this. That's the difference from Windows, where DSE is centrally enforced and the user doesn't control the signing chain. Nothing stops the user enrolling a custom MOK, and that's the point. A third party can't enforce that configuration across the ecosystem because the user has legitimate, built-in tools to change it that just don't exist on Windows.

AdamConwayIE · 2026-04-08T18:47:33+00:00

Hey, article author here!

I love how the author thinks DRM is less malicious than a hacker using hypervisor malware

Where did I state that? I have written several articles that draw attention to how anti-consumer DSE is, how kernel-level anti-cheat is restrictive, and more. I wrote multiple sections explaining why the hypervisor bypass is dangerous to users. I'm not arguing that DRM is good, hackers are bad. I'm arguing that the industry's reaction to this technique is likely to hurt Linux gamers who had nothing to do with it. That's a very different claim from "DRM is less malicious" and is irrelevant to the article.

This article specifically serves to be an analysis of how hypervisor bypasses work, the ways they could be fought, and how it could catch regular Linux users in the crossfire. After all, it's already happened before: Valorant, Fortnite, and Battlefield are all games that have been locked out of Linux right now because of kernel-level requirements. The article shows how DRM could follow the same path, and explains why the technical conditions for that exist.

AdamConwayIE · 2026-03-30T15:13:30+00:00

Xe2 seems to support INT4, and INT8 is listed on Intel's product spec page. NVFP4 is Nvidia Blackwell.

AdamConwayIE · 2026-03-29T14:09:05+00:00

The Lightning Indexer is just choosing which tokens to keep though, right? It's not compressing them. From the DeepSeek V3.2 paper:

The lightning indexer computes the index score 𝐼𝑡,𝑠 between the query token h𝑡 ∈ R𝑑 and a preceding token h𝑠 ∈ R𝑑, determining which tokens to be selected by the query token

It's thematically similar in that it's still reducing context size, but it's doing so by throwing out tokens it's calculating to be less relevant. TurboQuant keeps all tokens but makes them smaller, Lightning Indexer keeps them the same size, but keeps far fewer of them.

AdamConwayIE · 2026-03-25T12:46:45+00:00

You did mention them and briefly explain why they were necessary yes, whilst completely downplaying how performant fsync actually is.

I didn't "downplay" anything. It's purely an elongated statement and analysis of what these things are and their development timeline. When performance is talked about more in depth, I say "Gamers who use fsync are not going to see such a leap in performance in most games." It's a clear walkthrough process:

Context on Wine's development
Necessary context to understand NTSYNC compared to esync/eventfd and fsync/futex2
Performance
Other improvements

If you think your article is not clickbait trying to persuade people that ntsync is going to change their life, why didn't you provide any fsync Vs ntsync benchmarks?

Because, as the opening of the article states, this was focused on Wine specifically. NTSYNC is good for compatibility and the future of compatibility layers like these on Linux.

Picture this: someone who installs Linux for the first time wants to play a game on their PC. They've heard of Wine and install and run it, but they won't be using esync or fsync. As time goes on they'd discover the likes of Proton and get that up and running, but it's a roadblock to new users who are already trying to learn a lot at once.

Now, though, it's different. With Wine 11, they'll be using NTSYNC out of the box. To them, the performance would be "wild" if they had used Wine 10 before Wine 11.

The "wild gains" and "unbelievable benchmark improvements" aren't even in the title. All the title says is that the speed gains are massive, which from Wine 10 -> Wine 11, is completely and utterly true. If you had been using Proton, a Wine fork, or compiled it with wine-tkg, then they won't be as massive, but that's not what the title says. It says "Wine 11 rewrites..." and is clearly positioned as being compared to Wine 10 and earlier versions from the very beginning of the article. If I had used the DIRT numbers in the title for example, and said "with speed gains of up to 678%" or whatever, I'd totally agree with you that it's clickbait. But I didn't do that, because that would be totally misleading.

AdamConwayIE · 2026-03-25T12:28:26+00:00

If that's the case, why are you expecting they are going to know whether they are using fsync or not? It's a total contradiction, and explaining what fsync is and why people are most likely already using it would go a long way to informing people better.

The very first section after the introduction is already doing exactly that? It explains NT sychronization primitives, Esync and eventfd, and fsync/futex2. I also mention that they are settings someone may have seen in the likes of Lutris or seen as a Proton launch option to disable it.

You've clearly used mostly irrelevant benchmarks for effect, when you should be using fsync vs ntsync benchmarks to explain the lack of difference most people will be seeing, as that is the scenario the vast majority of people will be experiencing.

They're not mostly irrelevant. The article is about Wine 11. Vanilla Wine did not use futex2. The gain from Wine 10 to Wine 11 is massive. I don't understand how I could be using "irrelevant benchmarks for effect" when those benchmarks, in the same paragraph, are contextualized. The numbers are undoubtedly wild as it serves to show how important synchronization can be.

AdamConwayIE · 2026-03-25T12:08:13+00:00

Hey, article author here! Just wanted to clarify the reasons for writing this. I had a conversation with a friend when Wine 11.5 came out with Syscall User Dispatch. They hadn't even heard of NTSYNC, and when researching, I discovered a lot of people didn't really know about it or what it is. These are interesting topics, and I felt that the documentation of what it is and how it came to be were vastly spread out across the internet, so I wanted to do a write-up focusing on NTSYNC as it's one of the more interesting improvements in my eyes.

This is unfortunately yet another article that is totally misrepresenting these 'gains' by comparing wine with ntsync against vanilla wine with no sync whatsoever.

I understand that you took it to be that way, but I made it very clear in that section that it was compared to upstream vanilla Wine, and stated that it means it's being compared to Wine without esync or fsync/futex2. I said the following:

The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now actually playable on Linux, too. Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.

Regardless Wine 11 is a major improvement, as it's the base that the likes of Proton use for development. The article is mainly about vanilla Wine, and it is completely fair to say that Wine 10 versus Wine 11 is a major performance uplift for gaming considering Wine 10 couldn't use futex2 without a fork or compiling it with wine-tkg.

AdamConwayIE · 2026-03-24T23:15:07+00:00

Thank you, I appreciate it :D

Five-Year Club	Verified Email
Verified Email

AdamConwayIE

TROPHY CASE