This is most annoying

Riot tells Ars kernel-level system could be removed if vulnerability is detected.

Source: Ring 0 of fire: Does Riot Games’ new anti-cheat measure go too far? | Ars Technica

Given Riot’s labor and cultural practices I’m not holding much hope for them being able to fix issues quickly when (not if) someone breaks their driver and turns it into a rootkit like Sony’s.

Another issue the article does not go into is the fact every major game publisher will develop their own kernel-mode driver or use a 3rd party service (like BattlEye) to do so, leading to issues within the kernel that will be:

  • A pain in the ass to diagnose
  • Hidden from the player
  • Likely will not provide any kind of error message since the developers will be afraid they could be used to break the driver.
  • The risk of collisions between drivers will be increased, with likely both publishers being the cause.

Microsoft can help but there’s only so much they can do before breaking compatibility with previous versions of Windows; Gamers don’t care as much but Microsoft does have to worry about their main customer base (enterprise) who will definitely not like having weird code fuck around with workstation kernels(like this, and what Swift is complaining about is mere user-level applications.

People with time and money will probably want to look at PCI Passthrough to be able to run games in a Windows VM and not have to worry about any of this fuckery. Something goes wrong? Just restore to a previous snapshot of the VM and carry on as usual.


The error message from Virtualbox reads:

"Cannot enable nested VT-x/AMD-V without nested-paging and unresricted guest execution!


Encountered this error when trying to run any VM under VirtualBox Version 6.0.12 r133076 (Qt5.6.2). I’m assuming all versions of VBox are affected when running under Windows 10.

Looking around the web found this reddit post where this solution is proposed:

PS C:\Windows\system32> bcdedit /set hypervisorlaunchtype off

On my system (Windows Version 10.0.18362.329) it didn’t ask for a reboot but even after rebooting VirtualBox still didn’t work. That’s when I remembered I had enabled the Virtual Machine Platform option in the “Turn Windows Features on or off” section of Programs and Features. Disabling this feature and rebooting allowed Virtualbox VMs to boot without issues.

Here’s how to disable the option through PowerShell with Admin rights:

PS C:\Windows\system32> Disable-WindowsOptionalFeature -online -FeatureName VirtualMachinePlatform

I’m not sure if other Hyper-V options would affect VirtualBox in the same way but it’d seem they do. Posting up here mostly so it doesn’t get lost in social media link morass.