From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f53.google.com (mail-yx1-f53.google.com [74.125.224.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6997447254C for ; Mon, 17 Aug 2026 21:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787002765; cv=none; b=sePVkGAS+3EKmsF+QhSs8fl61a9PuuL9qWflD6gySDsrkfGT+G4df30ipcckD6JLh09UfVAoGUDSwDegQvJG2h04Rkl7/UrEwFBgMSGk/olxaQQm26WT9usRvSmgCoGxxlwu2yFo57ipmmwef5yFneDCuWaZ7W7afWKw8jFSAz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787002765; c=relaxed/simple; bh=JX/yU6U3E2Rxsb4oF+MJmhH81TAKa6b8vwmg6WcbaOQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:MIME-Version: Content-Type; b=SxTots1KnCTLeEmoXBqX82ds90UOdZ9O8P8pccKcSUKz8xMVRdblMU8wa9GxYZ7cHnQ2bvJAnOwMd6raLgNTkTGUQhn5EOxnRYsyNnMY1osc5XdchSaVCfClt/wVFpBnt0AUYMJ7qOtm0dc7GLdsdm8R1lowMWL2BkaAv9vlYSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fHju7/Ux; arc=none smtp.client-ip=74.125.224.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fHju7/Ux" Received: by mail-yx1-f53.google.com with SMTP id 956f58d0204a3-66c8e41f703so2477931d50.1 for ; Mon, 17 Aug 2026 14:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787002761; x=1787607561; darn=vger.kernel.org; h=content-type:content-transfer-encoding:mime-version:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JX/yU6U3E2Rxsb4oF+MJmhH81TAKa6b8vwmg6WcbaOQ=; b=fHju7/UxE+leuEUxD+Di+xayqUTLDFgwxVq/npzKD46+hKTmlpXl5I0EGZp2l8gvd4 LjjW44ExJ2c8xQflGRostoJms4SGX+n/OXfseNWIVXTm13E4S3+IjoS/DRvJ/3ZZ0ab/ CATnpJr4q7dHcoig0mEZBECmyC16R84PZyfu2dXaLVcM6+uHK+QEvpT208LRrF+KGH8C mAtKNVZHiBSq44Vu1/+VB6X66ZZvJvaVyYCYWZzOIH9LBGqdoFk1efa25Be9lSwOHJjb 2JwftH8D7XwL2oZ1X9zSGJ4g6Vl4tUmcc9/0DXUfnWV+yq2OJaI9HRVrs3dyIwo3UjRK yg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787002761; x=1787607561; h=content-type:content-transfer-encoding:mime-version:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=JX/yU6U3E2Rxsb4oF+MJmhH81TAKa6b8vwmg6WcbaOQ=; b=sFKJGxLlS1tHdvGwUjn9w00/cdQjpS/VaywElRYXSVXi0mLBgakYQKSUY9qary9C8P tIWVpxEPu5Pp3YzQpHbckXXnjswpRUVbKcgr7tRabGhpv/Opirc7UhaOG2aeRbPH0kyB 5jnVniHWcEfdT8SzLQrfzr6j1raxH7T5x4fS6aWBuGJ6qQ+jQyX0ZKSLB1+/czMBuQXj JlwwatuzPOrjTdp7N2mTYCa9aHXobs3HmRRtY5gMa+BUgpjIm8ZRNiAZMz+hBJ7HfPxA U1yOM16ONeTUYjQFn+29DZvRC4WoP8onwhB0LdTCNT8AR6b7iMt5dhCdBjOG2CRJhS9z iQ3g== X-Forwarded-Encrypted: i=1; AHgh+RozgO2jgD8J5GQjjFAqDip8owFUZHV9sVBAAG8c4qkvYq94N9OnrrGber5HacchW29GlIl2uv7+93qDrNc=@vger.kernel.org X-Gm-Message-State: AOJu0YzvbLNr2pJiqUcglFBRBWsCdRLOd84ROVfdxwlGf9lebHDCRGPu Hvixjhbl9y+8uRPL1XwxjoOIJtdIYaXplsUoN5SOKSxQN5FviMwHbVBH X-Gm-Gg: AR+sD10JOALNKjGfLKlq0xwgPY53sUeWcpgGT/Ya5aIOUSGFyOFry/o1bRRciri+CSE 2JgXckI4nWfM/xx/Y3aHj4vEQGVrlKPvOqHsX97odvm3NsRoWoTndZWA7jP5gywZbaD3z0d8cVd fG0ncVU2K2PLolFb6OxSxGRgGPQWJarhQFb6iYwiRUtCq/k8JrsHlv0KQUDiostGcYw3uJs222C 49pXrqD7XPVP71Oz08+7XFc6sTk4l/8Uu7wx4LRtB36ZO3+u2fUR7DfF8PJePv6ObJvSwBpcgdl CmyTPq6YMdwhqYBq2JeBC/NFMDvIQFAcgxSH1KdxU7CToNzFghfkuwDs6WmzAgCx8+bUjTKwWhC gbnrJbC38U/wgSzyUoflvSAeraMf7/NbUHDqjXrwQhXB8i2nYq1ZnSJnLQZO/aExIxoPW2s1Lkw ksEWA/sLjs2CJFqUi6AKNDFcphriQYPLjkYz+FLV8DJIS2mJXz+F+GGvmpihi2q5URduuNk3EEB s/Xd5G9dJg2k+WGmjUPmK/U5zuMbgsIWnUMY2ORRNDeRsqmvkb+v2OxsejM5Cj/OrJDsSfAD20e RnYfTmUrkCNvubh6n/rxag4La4a4MT19WM9jRg== X-Received: by 2002:a05:690e:d07:b0:66c:85e3:7f2e with SMTP id 956f58d0204a3-66cb9e45c23mr1248987d50.36.1787002760896; Mon, 17 Aug 2026 14:39:20 -0700 (PDT) Received: from fractal.localnet (107-202-193-186.lightspeed.stlsmo.sbcglobal.net. [107.202.193.186]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-66cb41e546csm1382192d50.5.2026.08.17.14.39.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 14:39:20 -0700 (PDT) From: Kenny Wottrich To: peterz@infradead.org Cc: andrew.cooper3@citrix.com, bp@alien8.de, linux-kernel@vger.kernel.org, ronan@rjp.ie, x86@kernel.org Subject: Re: UMIP and clearcpuid= Date: Mon, 17 Aug 2026 16:39:19 -0500 Message-ID: In-Reply-To: <20260814132316.GZ687043@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Fri, Aug 14, 2026 at 01:50:45PM +0200, Peter Zijlstra wrote: > 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. The post in question is here: https://cs.rin.ru/forum/viewtopic.php?p=3550884#p3550884 The relevant analysis is included in the patch in the linked gist: https://gist.github.com/ChrisTX/bb4a26c4e66dc46f716b0150a53bea8e > At the moment, a GDT limit of 0 is returned, to indicate that the GDT > descriptor is bogus, since the base address is bogus. > However, a GDT limit of 0 still implies that the GDT descriptor at the > returned base is one byte long, since the GDT limit specifies the last byte > of the GDT descriptor. This is specifically pointed out in the Intel Software > Architecture manual. > Since GDT limits should, according to the Intel Software Architecture > manual, be a multiple of 8 bytes minus 1, a limit of 0 is also unexpected > for that reason. > Certain digital rights management software appears to use the GDT limit as a > data point to lock the system to, this choice of 0 has the practical effect > that switching UMIP on or off can make a reauthorisation necessary. > As the GDT limit is hardcoded to be (GDT_ENTRIES * 8) - 1 anyway, we can > just as well return GDT_SIZE - 1 and thus return the same limit regardless > of whether UMIP is on or off, thus avoiding this spurious difference between > both states. This also aligns with what software should expect the GDT limit > to be according to the manual.