Re: UMIP and clearcpuid=

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.