Re: UMIP and clearcpuid=

On Thu, Jun 11, 2026 at 08:37:36PM +0200, Peter Zijlstra wrote:
> And UMIP really is useful; these are gnarly instructions you really
> don't want, so as along as it all runs it should be fine. I suppose I
> should go re-enable it on my own machine and actually spend some time on
> it if/when I find another game that flat out doesn't work with the
> emulation.

I've been searching the web a bit and found this:

  https://cs.rin.ru/forum/viewtopic.php?f=10&t=159989

That's patches and crud to work around Denuvo DRM for them software
pirates Arrr!. Anyway, the interesting bit here is that they require
UMIP to be disabled.

AFAICT the DRM thing fingerprints the system and what they do is spoof
it all to make all machines look the same, so a single prepared game
image works, because fingerprint matches.

The fingerprint includes CPUID, which we have CPUID faulting for (they
use a hypervisor for early AMD chips, because AMD 'forgot' to allow
native CPUID faulting) but also UMIP.

The problem with our UMIP emulation is that they break the fingerprint,
while with UMIP disabled, the Linux values match the Windows values
close enough for it to magically work.

When I first found this (a few weeks ago, during holidays), the forum
post seemed to have a little more detail, specifically there was some
patch to 'fix' the UMIP spoofing. I cannot readily find that now.

And while in general I don't suppose we should condone software piracy,
I don't think adding a prctl() to influence the UMIP emulation; much
like we have CPUID fault handling, is too much to ask.

The earlier forum post seemed to be cross about UMIP emulation not
working the same as CPUID faulting, but that misses the fundamental
difference between these two. CPUID faulting is opt-in, while UMIP
emulation is always on and cannot cause faults userspace is not
expecting.

Anyway, just figured I'd share.