All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: peterz@infradead.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	bp@alien8.de, linux-kernel@vger.kernel.org, ronan@rjp.ie,
	x86@kernel.org
Subject: Re: UMIP and clearcpuid=
Date: Fri, 14 Aug 2026 13:57:28 +0100	[thread overview]
Message-ID: <7f448edb-e618-4cfc-b2e5-cc8d58c2f305@citrix.com> (raw)
In-Reply-To: <20260814121247.GI788244@noisy.programming.kicks-ass.net>

> 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

  reply	other threads:[~2026-08-14 12:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-10 19:46 UMIP and clearcpuid= Ronan Pigott
2026-06-10 20:00 ` Borislav Petkov
2026-06-10 20:41   ` Ronan Pigott
2026-06-10 23:55     ` Borislav Petkov
2026-06-11  7:53       ` Peter Zijlstra
2026-06-11 16:09         ` Borislav Petkov
2026-06-11 18:37           ` Peter Zijlstra
2026-06-12  2:21             ` Borislav Petkov
2026-06-12  6:42               ` Peter Zijlstra
2026-06-12 14:49                 ` Borislav Petkov
2026-08-14 11:50             ` Peter Zijlstra
2026-08-14 12:12               ` Peter Zijlstra
2026-08-14 12:57                 ` Andrew Cooper [this message]
2026-08-14 13:23                   ` Peter Zijlstra
2026-08-14 12:19             ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f448edb-e618-4cfc-b2e5-cc8d58c2f305@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=ronan@rjp.ie \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.