Re: UMIP and clearcpuid=

On Fri, Aug 14, 2026 at 01:50:45PM +0200, Peter Zijlstra wrote:
> 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.

Supposedly, according to Gemini, the below 'patch' is sufficient to
'fix' things. I tried and failed to get a reference to the thread
where it originated though.


---
/* arch/x86/kernel/umip.c */

 static int emulate_umip_insn(struct insn *insn, int insn_idx,
 			     unsigned char *data, int *data_size)
 {
-	/* Current upstream logic: sets up a high-canonical dummy address space */
-	unsigned long dummy_base = -1UL << 32; /* Taints high 16 bits with 0xFFFF... */
+	/* The 'Compatibility Fix': Forces high 16 bits to 0x0000 to mirror Windows */
+	unsigned long dummy_base = 0x00000000FFFF0000UL;
...