Apple Processor ID lowercase since 5.4.0

[george-kay]

Since we updated to newest 5.8.5 version our licenses which are based on hardware information via oshi become invalid.

We downgraded and found out it began with 5.4.0.

Old Processor Id Example:
centralProcessor.getProcessorID() "bfebfbff000506e3"
New since 5.4.0:
centralProcessor.getProcessorID() "BFEBFBFF000506E3"

Investigated only on Apple at the moment.

Any Ideas?

Joerg

[dbwiddis]

Any Ideas?

The change occurred in #1485 where a String.format() changed from using %08X to %08x. Sorry about that...

As far as workarounds, for string comparisons, convert using toLowerCase() or toUpperCase(). Or parse the hex to a 64-bit number.

I don't think OSHI has ever enforced a particular format for Processor ID and in some cases there are also endianness differences as well.

[dbwiddis]

Also consider on M1 you may get a different result if the user is executing the JVM under Rosetta.

[dbwiddis]

well so our licenses will change anyway. Because anything we'll change in code will also change license content as we hash the values.

If you take OSHI's result and do toUpperCase() on it, you should not have to change what you're doing.

Realize that on Linux, you may get a different result running with elevated permissions or not. And Process ID is primarily an intel thing, so the result you get from an ARM or other chip may not be useful.

[george-kay]

Also consider on M1 you may get a different result if the user is executing the JVM under Rosetta.

this is fine - OS update may cause need for new license activation

If you take OSHI's result and do toUpperCase() on it, you should not have to change what you're doing.

if we limit the change with condition operatingSystem.getManufacturer()=='Apple' it may work - otherwise we will change processor id for other (now working) licenses

And Process ID is primarily an intel thing, so the result you get from an ARM or other chip may not be useful.

You suggest we should check processor ID only for Intel Architecture Processors and skip it for others?

[dbwiddis]

if we limit the change with condition operatingSystem.getManufacturer()=='Apple' it may work - otherwise we will change processor id for other (now working) licenses

I think uppercase tends to be the intended default and works for Windows, Linux-with-root, Linux-without-cpuid-installed, and OSHI-generated values that are guessed at. The only lowercase ones out there are

• pre-M1-compatible OSHI version on macOS
• Linux without root but with cpuid program installed

If I do anything to enforce consistency I'd probably make that one Linux exception uppercase.

You suggest we should check processor ID only for Intel Architecture Processors and skip it for others?

Honestly I'd suggest to avoid using processor ID for licensing. Here's a quote from the Javadoc for it:

Gets the Processor ID. This is a hexidecimal string representing an 8-byte
value, normally obtained using the CPUID opcode with the EAX register set to 1.
The first four bytes are the resulting contents of the EAX register, which
is the Processor signature, represented in human-readable form by
#getIdentifier(). The remaining four bytes are the contents of the
EDX register, containing feature flags.

For processors that do not support the CPUID opcode this field is populated
with a comparable hex string. For example, ARM Processors will fill the first
32 bytes with the MIDR. AIX PowerPC Processors will return the machine ID.

NOTE: The order of returned bytes is platform and software dependent. Values
may be in either Big Endian or Little Endian order.

NOTE: If OSHI is unable to determine the ProcessorID from native sources, it
will attempt to reconstruct one from available information in the processor
identifier.

Note the multiple caveats about "processors that do not support the CPUID opcode" and "order of returned bytes is platform and software dependent". Some examples:

• On Linux:
  • Getting the actual processor ID requires running with root permissions, and returns ED 06 09 00 FF FB EB BF
  • If that fails but cpuid package is installed, it parses that, returning 1f8bfbff000906ed. Note the endianness reversal.
  • If that fails it constructs a CPUID from model, stepping, family, and flags, but doesn't know "cpuType" and assumes 0. It would return ED060900FFFBEBBF.
  • If it's a non-intel chip it tries to create a CPUID equivalent such as MIDR. This works somewhat for ARM chips but does nothing for SPARC or POWER chips, and I'm not sure what it would do for ARM big.LITTLE chips.
• On macOS
  • M1 on a machine with a JDK that supports native instructions reports 0100000C1B588BB3
  • M1 on the identical machine with an older JDK uses Rosetta and reports 00000007573B5EEC
  • I haven't yet implemented M1 Pro or M1 Max, they may be different
• On Windows
  • Reports the uppercase version for intel chips, same caveats as before for non-intel chips

I haven't gone through the code for the other OS's but hopefully you see enough inconsistency just with Linux to understand that some measure of pre-parsing is required. Removing spaces, evaluating endianness differences, probably doing one version with the second set of flag bits (first with cpuid) set to 0 and one without, one testing for a blank/zero/empty string result.

In all cases, the CPUID represents a 64-bit value, and parsing the result to a long is probably a better approach than hashing the string output.

So while I apologize for the changed case, the reality is that this is a particularly temperamental output and while you might use it as a "clue" to the same machine, I would not invalidate a license based on a different Processor ID.

[george-kay]

thx - processor ID ist not the only part of machine identification but it's one of it. For us its more about that these values don't change ocassionally. We will think about removing it from identification but beyond the current issue (on mac developer machines) we didn't have one in the last five years (on windows and unix servers).

Thanks for your help!