UMIP and clearcpuid=

UMIP and clearcpuid=

[Ronan Pigott]

Hi,

In [1] the clearcpuid= flag was hidden, but afaik this remains the only way to
disable UMIP. At the time UMIP was enabled, clearcpuid was apparently
determined to be the appropriate method of disablement in [2], and it remains
recommended by the documentation in [3].

If clearcpuid is no good, can we have a sanctioned method to disable UMIP
protections instead then?

[1] https://patch.msgid.link/20260520202508.160112-1-bp@kernel.org

[2] https://lore.kernel.org/lkml/1478760361.2551.21.camel@ranerica-desktop/

[3] https://docs.kernel.org/arch/x86/cpuinfo.html#the-feature-is-disabled-at-boot-time

Cheers,

Ronan

Re: UMIP and clearcpuid=

[Borislav Petkov]

On Wed, Jun 10, 2026 at 07:46:11PM +0000, Ronan Pigott wrote:
> In [1] the clearcpuid= flag was hidden, but afaik this remains the only way to
> disable UMIP.

The reason for wanting to disable it being?

> At the time UMIP was enabled, clearcpuid was apparently determined to be the
> appropriate method of disablement in [2],

Don't confuse "appropriate" with "might be good enough" ;)

> and it remains recommended by the documentation in [3].

That doc says:

"DO NOT USE this cmdline option in production - it is meant to be used only as
a quick’n’dirty debugging aid to rule out a feature-enabling code is the
culprit. If you use it, it’ll taint the kernel."

> If clearcpuid is no good, can we have a sanctioned method to disable UMIP
> protections instead then?

Let's figure out the use case first pls.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: UMIP and clearcpuid=

[Ronan Pigott]

Hi Boris,

June 10, 2026 at 1:00 PM, "Borislav Petkov" <bp@alien8.de> wrote:

> The reason for wanting to disable it being?

My use case is playing Windows video games via Wine. For whatever reason,
they like to use these instructions:

  $ journalctl -b -g umip -o cat --since=-5m
  umip_printk: 117 callbacks suppressed
  umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.
  umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: For now, expensive software emulation returns the result.
  umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: SGDT instruction cannot be used by applications.
  umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: For now, expensive software emulation returns the result.
  umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.

I don't think I benefit from the UMIP protection or the emulation, so I'd
rather just disable it. clearcpuid still works, but results in a tainted
kernel etc:

  kernel: clearcpuid: force-disabling CPU feature flag: umip
  kernel: !!! setcpuid=/clearcpuid= in use, this is for TESTING ONLY, may break things horribly. Tainting kernel.

so I think a umip=no flag as originally proposed could be preferable. Would
that be acceptable?

Cheers,

Ronan

Re: UMIP and clearcpuid=

[Borislav Petkov]

On Wed, Jun 10, 2026 at 08:41:02PM +0000, Ronan Pigott wrote:
> My use case is playing Windows video games via Wine. For whatever reason,
> they like to use these instructions:
> 
>   $ journalctl -b -g umip -o cat --since=-5m
>   umip_printk: 117 callbacks suppressed
>   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.
>   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: For now, expensive software emulation returns the result.
>   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: SGDT instruction cannot be used by applications.
>   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: For now, expensive software emulation returns the result.
>   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.
> 
> I don't think I benefit from the UMIP protection or the emulation, so I'd

Question is, do you benefit from disabling the UMIP emulation. Any noticeable
game performance increase?

> rather just disable it. clearcpuid still works, but results in a tainted
> kernel etc:
> 
>   kernel: clearcpuid: force-disabling CPU feature flag: umip
>   kernel: !!! setcpuid=/clearcpuid= in use, this is for TESTING ONLY, may break things horribly. Tainting kernel.

Right, I don't think a tainted kernel would be a problem but yeah...

I still think that it would make sense to issue a big fat warning when
disabling UMIP so that people know.
 
> so I think a umip=no flag as originally proposed could be preferable. Would
> that be acceptable?

umip=disable or umip=off

I guess.

Other than that, I guess that's a valid use case I'd say. Let's see what the
others think.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: UMIP and clearcpuid=

[Peter Zijlstra]

On Wed, Jun 10, 2026 at 04:55:01PM -0700, Borislav Petkov wrote:
> On Wed, Jun 10, 2026 at 08:41:02PM +0000, Ronan Pigott wrote:
> > My use case is playing Windows video games via Wine. For whatever reason,
> > they like to use these instructions:
> > 
> >   $ journalctl -b -g umip -o cat --since=-5m
> >   umip_printk: 117 callbacks suppressed
> >   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.
> >   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: For now, expensive software emulation returns the result.
> >   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: SGDT instruction cannot be used by applications.
> >   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fec20: For now, expensive software emulation returns the result.
> >   umip: StreetFighter6.[3837] ip:15f523f4d sp:524fecb0: SGDT instruction cannot be used by applications.
> > 
> > I don't think I benefit from the UMIP protection or the emulation, so I'd
> 
> Question is, do you benefit from disabling the UMIP emulation. Any noticeable
> game performance increase?
> 
> > rather just disable it. clearcpuid still works, but results in a tainted
> > kernel etc:
> > 
> >   kernel: clearcpuid: force-disabling CPU feature flag: umip
> >   kernel: !!! setcpuid=/clearcpuid= in use, this is for TESTING ONLY, may break things horribly. Tainting kernel.
> 
> Right, I don't think a tainted kernel would be a problem but yeah...
> 
> I still think that it would make sense to issue a big fat warning when
> disabling UMIP so that people know.
>  
> > so I think a umip=no flag as originally proposed could be preferable. Would
> > that be acceptable?
> 
> umip=disable or umip=off
> 
> I guess.
> 
> Other than that, I guess that's a valid use case I'd say. Let's see what the
> others think.

So my own game box also has this; aside from the dmesg spam, there was
one game that just plain didn't run. I forgot what it was, but I'm sure
it was related to some dodgy DRM thing.

It is really annoying having to disable UMIP though, its bugged me, just
not enough to ever actually do anything about it.

Re: UMIP and clearcpuid=

[Borislav Petkov]

On Thu, Jun 11, 2026 at 09:53:11AM +0200, Peter Zijlstra wrote:
> So my own game box also has this; aside from the dmesg spam, there was
> one game that just plain didn't run. I forgot what it was, but I'm sure
> it was related to some dodgy DRM thing.

Right,

> It is really annoying having to disable UMIP though, its bugged me, just
> not enough to ever actually do anything about it.

Well, what else could we do? Whitelist processes, make it more fine-grained or
so...?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: UMIP and clearcpuid=

[Peter Zijlstra]

On Thu, Jun 11, 2026 at 09:09:46AM -0700, Borislav Petkov wrote:

> > It is really annoying having to disable UMIP though, its bugged me, just
> > not enough to ever actually do anything about it.
> 
> Well, what else could we do? Whitelist processes, make it more fine-grained or
> so...?

Perhaps just one print per task might be a good start? Something like
so?

I don't think anything hits this hard enough to matter performance wise;
but the wine stuff can hit them often enough that the dmesg spam is
annoying, and there's really nothing much you can do about it.

This is somewhat similar to the split lock stuff, yeah, they're bad, but
nobody is going to be fixing those games.

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.

---
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index 3ce99cbcf187..83517d5b8eae 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -90,49 +90,6 @@ static const char * const umip_insns[5] = {
 	[UMIP_INST_STR] = "STR",
 };
 
-#define umip_pr_err(regs, fmt, ...) \
-	umip_printk(regs, KERN_ERR, fmt, ##__VA_ARGS__)
-#define umip_pr_debug(regs, fmt, ...) \
-	umip_printk(regs, KERN_DEBUG, fmt,  ##__VA_ARGS__)
-
-/**
- * umip_printk() - Print a rate-limited message
- * @regs:	Register set with the context in which the warning is printed
- * @log_level:	Kernel log level to print the message
- * @fmt:	The text string to print
- *
- * Print the text contained in @fmt. The print rate is limited to bursts of 5
- * messages every two minutes. The purpose of this customized version of
- * printk() is to print messages when user space processes use any of the
- * UMIP-protected instructions. Thus, the printed text is prepended with the
- * task name and process ID number of the current task as well as the
- * instruction and stack pointers in @regs as seen when entering kernel mode.
- *
- * Returns:
- *
- * None.
- */
-static __printf(3, 4)
-void umip_printk(const struct pt_regs *regs, const char *log_level,
-		 const char *fmt, ...)
-{
-	/* Bursts of 5 messages every two minutes */
-	static DEFINE_RATELIMIT_STATE(ratelimit, 2 * 60 * HZ, 5);
-	struct task_struct *tsk = current;
-	struct va_format vaf;
-	va_list args;
-
-	if (!__ratelimit(&ratelimit))
-		return;
-
-	va_start(args, fmt);
-	vaf.fmt = fmt;
-	vaf.va = &args;
-	printk("%s" pr_fmt("%s[%d] ip:%lx sp:%lx: %pV"), log_level, tsk->comm,
-	       task_pid_nr(tsk), regs->ip, regs->sp, &vaf);
-	va_end(args);
-}
-
 /**
  * identify_insn() - Identify a UMIP-protected instruction
  * @insn:	Instruction structure with opcode and ModRM byte.
@@ -322,8 +279,9 @@ static void force_sig_info_umip_fault(void __user *addr, struct pt_regs *regs)
 	if (!(show_unhandled_signals && unhandled_signal(tsk, SIGSEGV)))
 		return;
 
-	umip_pr_err(regs, "segfault in emulation. error%x\n",
-		    X86_PF_USER | X86_PF_WRITE);
+	pr_err("%s[%d] ip:%lx sp:%lx: segfault in emulation. error%x\n",
+	       tsk->comm, task_pid_nr(tsk), regs->ip, regs->sp,
+	       X86_PF_USER | X86_PF_WRITE);
 }
 
 /**
@@ -375,10 +333,13 @@ bool fixup_umip_exception(struct pt_regs *regs)
 	if (umip_inst < 0)
 		return false;
 
-	umip_pr_debug(regs, "%s instruction cannot be used by applications.\n",
-			umip_insns[umip_inst]);
-
-	umip_pr_debug(regs, "For now, expensive software emulation returns the result.\n");
+	if (!current->reported_umip_emu) {
+		pr_debug("%s[%d] ip:%lx sp:%lx: %s instruction cannot be used by application; "
+			 "will be emulated.\n",
+			 current->comm, task_pid_nr(current), regs->ip, regs->sp,
+			 umip_insns[umip_inst]);
+		current->reported_umip_emu = 1;
+	}
 
 	if (emulate_umip_insn(&insn, umip_inst, dummy_data, &dummy_data_size,
 			      user_64bit_mode(regs)))
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c88fc10e9c38..f6ef5b519ad6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1044,6 +1044,9 @@ struct task_struct {
 #ifdef CONFIG_X86_BUS_LOCK_DETECT
 	unsigned			reported_split_lock:1;
 #endif
+#ifdef CONFIG_X86_UMIP
+	unsigned			reported_umip_emu:1;
+#endif
 #ifdef CONFIG_TASK_DELAY_ACCT
 	/* delay due to memory thrashing */
 	unsigned                        in_thrashing:1;

Re: UMIP and clearcpuid=

[Borislav Petkov]

On Thu, Jun 11, 2026 at 08:37:36PM +0200, Peter Zijlstra wrote:
> Perhaps just one print per task might be a good start? Something like
> so?
> 
> I don't think anything hits this hard enough to matter performance wise;
> but the wine stuff can hit them often enough that the dmesg spam is
> annoying, and there's really nothing much you can do about it.
> 
> This is somewhat similar to the split lock stuff, yeah, they're bad, but
> nobody is going to be fixing those games.
> 
> 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.

Yah, I guess... I don't play them games so meh, but sure, makes sense to me.
I guess we can have people test it and see whether it helps.. maybe...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: UMIP and clearcpuid=

[Peter Zijlstra]

On Thu, Jun 11, 2026 at 07:21:58PM -0700, Borislav Petkov wrote:
> On Thu, Jun 11, 2026 at 08:37:36PM +0200, Peter Zijlstra wrote:
> > Perhaps just one print per task might be a good start? Something like
> > so?
> > 
> > I don't think anything hits this hard enough to matter performance wise;
> > but the wine stuff can hit them often enough that the dmesg spam is
> > annoying, and there's really nothing much you can do about it.
> > 
> > This is somewhat similar to the split lock stuff, yeah, they're bad, but
> > nobody is going to be fixing those games.
> > 
> > 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.
> 
> Yah, I guess... I don't play them games so meh, but sure, makes sense to me.
> I guess we can have people test it and see whether it helps.. maybe...

I have kids, playing games is mandatory ;-) At least I got out of having
to join Fortnite on account of it not running on Linux (silver lining
and all that).

Re: UMIP and clearcpuid=

[Borislav Petkov]

On Fri, Jun 12, 2026 at 08:42:02AM +0200, Peter Zijlstra wrote:
> I have kids, playing games is mandatory ;-) At least I got out of having
> to join Fortnite on account of it not running on Linux (silver lining
> and all that).

LOOL, I can imagine the "discussion" at the house...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: UMIP and clearcpuid=

[Peter Zijlstra]

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.

Re: UMIP and clearcpuid=

[Peter Zijlstra]

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;
...

Re: UMIP and clearcpuid=

[Peter Zijlstra]

On Thu, Jun 11, 2026 at 08:37:36PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 11, 2026 at 09:09:46AM -0700, Borislav Petkov wrote:
> 
> > > It is really annoying having to disable UMIP though, its bugged me, just
> > > not enough to ever actually do anything about it.
> > 
> > Well, what else could we do? Whitelist processes, make it more fine-grained or
> > so...?
> 
> Perhaps just one print per task might be a good start? Something like
> so?
> 
> I don't think anything hits this hard enough to matter performance wise;
> but the wine stuff can hit them often enough that the dmesg spam is
> annoying, and there's really nothing much you can do about it.

Apparently some games are hitting this rather hard:

  https://www.reddit.com/r/linux_gaming/comments/1qdj79f/is_mhwilds_performance_throttled_by_an_expensive/  

That seems to suggest the game is doing DLC checks on *EVERY* frame
while in a settlement. That's absolutely bonkers, but whatever.

Re: UMIP and clearcpuid=

[Andrew Cooper]

> 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;
> ...

My reading of those notes is that the game wants to see precisely 0x7f
in the limit field.

But, it also sounds like what they really want is for UMIP to just
SIGSEGV like any other privilege violation.  They're already emulating
CPUID via the SIGSEGV handler.

Overall, we probably want umip=disable|emulate.  If you want it per
task, then that will involve writing CR4 on the context switch path.

The sad thing is that UMIP is too little too late.  We already point the
GDT and LDT at read-only mappings in the first place to work around the
problem on non-UMIP platforms, so that SGDT/SIDT become less useful to
an attack.  STR/SLDT/SMSW are practically useless to start with.

~Andrew

Re: UMIP and clearcpuid=

[Peter Zijlstra]

On Fri, Aug 14, 2026 at 01:57:28PM +0100, Andrew Cooper wrote:
> > 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;
> > ...
> 
> My reading of those notes is that the game wants to see precisely 0x7f
> in the limit field.

Yeah, probably.

> But, it also sounds like what they really want is for UMIP to just
> SIGSEGV like any other privilege violation.  They're already emulating
> CPUID via the SIGSEGV handler.

That is indeed what I remember reading. But I was thinking that perhaps
we want to put limits on what exactly we allow being returned. Hence I
was thinking a prctl() interface might be preferable. The round-trip
through a signal handler will only make the whole thing slower still.

> Overall, we probably want umip=disable|emulate.  If you want it per
> task, then that will involve writing CR4 on the context switch path.

Well, not if we always emulate, then all we have is a bit to check on
exception. If set, round-trip to a signal handler to get the values,
otherwise return default values.

> The sad thing is that UMIP is too little too late.  We already point the
> GDT and LDT at read-only mappings in the first place to work around the
> problem on non-UMIP platforms, so that SGDT/SIDT become less useful to
> an attack.  STR/SLDT/SMSW are practically useless to start with.

There is that.

But perhaps there is also an argument to simply doing the above little
patch. I mean, any value is architecturally allowed, but from a
compatibility POV software seems to 'rely' on certain values more than
others.

That, and not dumping a printk for every single time we hit this thing
:-)