Re: UMIP and clearcpuid=

[Peter Zijlstra <peterz@infradead.org>]

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
:-)