From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DD644657E5 for ; Fri, 14 Aug 2026 13:23:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786713808; cv=none; b=vF4aDbL/EgwBJmZ5kpsUw4VfoxPKuXx0EVXUUFasNo3rv3SYBhAM2YHL1f0FgEdfN8X9tEB1O+nFGLCdOfGLEypnyLYGBi5LGLctPaCCq84fsy9qbbcDP+r8i/V53uN6NNuzYp/0H/ROvvPaLAsh7yKcuyDbIpqRdjBZEcaNQzo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786713808; c=relaxed/simple; bh=mEyoit1WYYiyDQM1+ZEbaa38IcRV4DBXqePH704MdkE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pvFeP8Z+o08PmAh80IZkobXhfIr5HMlMFCmsl3BMNO0NQKIgZr6ER+/HMIWAOHWxmyFCToBFAz+BvsV2QMSIydCweMvP+hdElb79EIDqYkizMuzQ4IKfui5PbJEHuIYuXXV60WKjW6L+UblVU0D0ou6LhlgXdMd8T/PcKlly6qc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ePIBTALb; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ePIBTALb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=rbpXQrbK6MZ/1HDHYhmjfItvLzRWaiVxVCfOO66vDP4=; b=ePIBTALbqN/8NivVgyyeCGQaJ6 3v1FWmxXxfCrgagZeq7OY3F8GeR9UzvClKnKveuWAapVGhS3Swxg96pnLjeXNmAv5Nb8PaiMbZBh9 RS/dft7Ym5p1JzNg6dNpmV6K23/E7HwMpqo3SbfzU/H3NWqkrmF0HaD/gsO+h+6UVdTiV7mROkBRx WojdOi52eoj7JXjFRYE64z44vNtvp3+uHRR7SUPaCa4eBrtmeGGtmxDVKrkWqbAbwKD+gM9cXONG7 BO/FEnf7wIrU0/4LxNZzp+43U3B/7NRg+9quL/sRy3yJ4JjIi31umkpf0tp06XjgLOb3wOxzB+8hd fJcZ6bgQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wursT-0000000Gwlb-49mt; Fri, 14 Aug 2026 13:23:18 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 8FBDC300323; Fri, 14 Aug 2026 15:23:16 +0200 (CEST) Date: Fri, 14 Aug 2026 15:23:16 +0200 From: Peter Zijlstra To: Andrew Cooper Cc: bp@alien8.de, linux-kernel@vger.kernel.org, ronan@rjp.ie, x86@kernel.org Subject: Re: UMIP and clearcpuid= Message-ID: <20260814132316.GZ687043@noisy.programming.kicks-ass.net> References: <20260814121247.GI788244@noisy.programming.kicks-ass.net> <7f448edb-e618-4cfc-b2e5-cc8d58c2f305@citrix.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7f448edb-e618-4cfc-b2e5-cc8d58c2f305@citrix.com> 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 :-)