Darwin Hardware: Imparity between Intel and ARM/M1 (Apple Silicon) Apple devices

[ChefAustin]

Describe the problem

There seems to be some bug(s) in ohai/lib/ohai/plugins/darwin/hardware.rb which result in Ohai data/keys being incongruous between Intel and M1-chipped Apple devices.

The following Ohai data is pulled from two separate machines running:

• macOS 12.2.1 (21D62)
• Chef Infra client v17.9.46 (the only difference being the M1 device is using the aarch64 package while the Intel device is using the x86_64

Ohai Version

$ /opt/chef/bin/ohai --version
Ohai: 17.9.0

Platform Version

 $  sw_vers
ProductName:	macOS
ProductVersion:	12.2.1
BuildVersion:	21D62

Ohai Output

I have made inline comments denoting the deviations between the two output hashes (UUID's have been purposefully altered): M1:

  "hardware": {
    "activation_lock_status": "activation_lock_disabled",
    "boot_rom_version": "7429.81.3",
    "chip_type": "Apple M1 Max",                             # Note the difference
    "machine_model": "MacBookPro18,2",
    "machine_name": "MacBook Pro",
    "number_processors": "proc 10:8:2",                      # Note the difference
    "os_loader_version": "7429.81.3",
    "physical_memory": "64 GB",
    "platform_UUID": "K666K666-6K66-K6K6-K6K6-K666K666K666",
    "provisioning_UDID": "K666K666-K666K666K666K666K",
    "serial_number": "K666K666K6",
    "operating_system": "macOS",
    "operating_system_version": "12.2.1",
    "build_version": "21D62",
    "architecture": "arm64",
    "storage": [
      {
        "name": "Data",
        "bsd_name": "disk3s5",
        "capacity": 994662584320
      },
      {
        "name": "Macintosh HD",
        "bsd_name": "disk3s1s1",
        "capacity": 994662584320
      }
    ]
  },

Intel:

  "hardware": {
    "activation_lock_status": "activation_lock_disabled",
    "boot_rom_version": "1715.81.2.0.0 (iBridge: 19.16.10744.0.0,0)",
    "cpu_type": "8-Core Intel Core i9",                              # Note the difference
    "current_processor_speed": "2,4 GHz",                            # Note the difference
    "l2_cache_core": "256 KB",                                       # Note the difference
    "l3_cache": "16 MB",                                             # Note the difference
    "machine_model": "MacBookPro16,1",
    "machine_name": "MacBook Pro",
    "number_processors": 8,
    "os_loader_version": "540.80.2~11",
    "packages": 1,                                                   # Note the difference
    "physical_memory": "64 GB",
    "platform_UUID": "C333C333-C333-C333-C333-C333C333C333",
    "platform_cpu_htt": "htt_enabled",                               # Note the difference
    "provisioning_UDID": "C333C333-C333-C333-C333-C333C333C333",
    "serial_number": "C333C333C333",
    "operating_system": "macOS",
    "operating_system_version": "12.2.1",
    "build_version": "21D62",
    "architecture": "x86_64",
    "storage": [
      {
        "name": "Macintosh HD - Data",
        "bsd_name": "disk1s2",
        "capacity": 4001907707904
      },
      {
        "name": "Macintosh HD",
        "bsd_name": "disk1s1s1",
        "capacity": 4001907707904
      },
    ],
    "battery": {                                                     # Note the difference
      "current_capacity": null,                                      # Note the difference
      "max_capacity": 7498,                                          # Note the difference
      "fully_charged": false,                                        # Note the difference
      "is_charging": false,                                          # Note the difference
      "charge_cycle_count": 222,                                     # Note the difference
      "health": "Good",                                              # Note the difference
      "serial": null,                                                # Note the difference
      "remaining": 0                                                 # Note the difference
    }                                                                # Note the difference
  },

Possible Solution

Still working my way through the code to see if I can conjure up a solution proposal but the first thing I noticed was that XML output from system_profiler SPPowerDataType -xml shows that the sppower_battery_charge_info dictionary's keys vary depending on architecture; for example: M1:

<key>sppower_battery_charge_info</key>
<dict>
	<key>sppower_battery_at_critical_level</key>
	<string>FALSE</string>
	<key>sppower_battery_fully_charged</key>
	<string>TRUE</string>
	<key>sppower_battery_is_charging</key>
	<string>FALSE</string>
	<key>sppower_battery_state_of_charge</key>
	<integer>100</integer>
</dict>

Intel:

<key>sppower_battery_charge_info</key>
<dict>
	<key>sppower_battery_fully_charged</key>
	<string>TRUE</string>
	<key>sppower_battery_is_charging</key>
	<string>FALSE</string>
	<key>sppower_battery_max_capacity</key>
	<integer>7548</integer>
	<key>sppower_battery_state_of_charge</key>
	<integer>100</integer>
</dict>

You'll see that the Intel devices have a sppower_battery_max_capacity kv-pair while M1 devices have a sppower_battery_at_critical_level kv-pair.

[ChefAustin]

Should this get prioritized, it might also be an opportune time to dig into https://github.com/chef/ohai/issues/1602 and https://github.com/chef/ohai/issues/1603

[ChefAustin]

FWIW: I've filed Feedback with Apple (FB9921451) about some of the key name discrepancies that exist between the different machine architectures.

[ChefAustin]

Apple responded to my Feedback submission and suffice it to say that they have no intention (or, in their words, "no obligation") to align output of system_profiler data on M1 and Intel devices. That being said, the general approach to gathering the hardware plugin's data on Darwin devices might need to be reevaluated.

One possible approach could be: Rather than seeking specific key-values from system_profiler's output, one could just target high-level system_profiler data types (like SPHardwareDataType) then have Ohai enumerate all (or almost all; I don't think any Ohai users care about the _name key) underlying keys and coerce them into the Hardware Mash.