run-efi-updater flag no longer works in macOS 11, Big Sur

[khronokernel]

With macOS Big Sur, it seems that even though the NVRAM variable is set macOS will still bless the firmware update during both install and update processes:

15:835 00:005 OCB: Perform boot EFI to dp PciRoot(0x0)/Pci(0x1D,0x0)/Pci(0x0,0x0)/NVMe(0x1,09-63-E3-44-8B-44-1B-00)/HD(1,GPT,11F42760-7AB1-4DB5-924B-D12C52895FA9,0x28,0x64000)/\EFI\APPLE\UPDATERS\MULTIUPDATER\MultiUpdater.efi (0/0)
15:864 00:029 OCI4: Manifest (3744) for 65666962 parse fail with code 1
15:877 00:012 OCI4: Manifest (3744) for 65666262 parse fail with code 1
15:890 00:012 OCI4: Manifest (3744) for 65666264 parse fail with code 1
15:896 00:005 OCSB: No suitable signature - Security Violation
15:903 00:006 OCB: Apple Secure Boot prohibits this boot entry, enforcing!
15:909 00:005 OCB: LoadImage failed - Security Violation

Verified the NVRAM arg is still present and wasn't modified:

nvram -p | grep "run-efi-updater"
  run-efi-updater   No

MultiUpdater-boot.txt

CC @Osy86

[vit9696]

References https://github.com/acidanthera/bugtracker/issues/948. The code in +[OSIUpdateFirmwareElement shouldUpdateFirmware] is unchanged. Something else got modified.

[vit9696]

I found another variable specific to MultiUpdater.efi — __FIRMWARE_UPDATE_OPTOUT. The variable should be set to Yes (as a string). Checked in -[OSIUpdateFirmwareElement runReturningError:]. Please test and report.

[khronokernel]

Tested and same results unfortunately. Will upload entire boot log shortly

Edit: Added logs, from inside USB installer, till hitting the Firmware update

CoolTerm Capture 2020-11-03 13-22-59.txt

[vit9696]

After some time investigating I can outline the following:

• macOS 11 does not use OSInstaller.framework at all. Instead the whole installation script is located in UpdateBrain.zip in com.apple.MobileSoftwareUpdate.UpdateBrainService.xpc. This executable looks like a reimplementation of what we had in OSInstaller.framework, and it no longer allows disabling firmware updates. Neither via boot arguments, nor via environment variables, not even via NVRAM variables. It unconditionally runs FirmwareUpdateLauncher.
• FirmwareUpdateLauncher will unconditionally execute various updates, and while some can be disabled (like usbcupdater via usbcupdater_bypass_usbc_updates variable equaling 1 as a string), some others cannot be (like dp2hdmiupdater, which will run MultiUpdater unconditionally on MacPro7,1 and Macmini8,1 regardless of the hardware or software on the platform).

• Interestingly, vbiosupdater is still broken and causes crashes when ATY,Rom# is a string instead of data OR has unexpected format. To fix that RX 5xxx owners should inject something like 123-456-789 via DeviceProperties. Last mentioned in https://github.com/acidanthera/bugtracker/issues/901.

  2020-11-03 20:14:14.454 FirmwareUpdateLauncher[333:4520] Running /usr/libexec/vbiosupdater (
      "-p",
      "/Volumes/Update/softwareupdate.293.YVbThO/source/boot/EFI",
      "-s"
  )
  2020-11-03 20:14:14.507 vbiosupdater[338:4527] -[__NSCFString bytes]: unrecognized selector sent to instance 0x7f8307504740
  2020-11-03 20:14:14.553 vbiosupdater[338:4527] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString bytes]: unrecognized selector sent to instance 0x7f8307504740'
  *** First throw call stack:
  (
    0   CoreFoundation                      0x00007fff34ddb083 __exceptionPreprocess + 242
    1   libobjc.A.dylib                     0x00007fff34b1217c objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff34e5d9a0 -[NSObject(NSObject) __retain_OA] + 0
    3   CoreFoundation                      0x00007fff34d42a57 ___forwarding___ + 1467
    4   CoreFoundation                      0x00007fff34d42408 _CF_forwarding_prep_0 + 120
    5   GPUInfo                             0x00007fff45e5d2af _Z17get_gpu_EFIATYROMP16__GPUWranglerGPUP14__CFDictionary + 662
    6   GPUWrangler                         0x00007fff3e56a1fa GPUWranglerForEachGPU + 234
    7   GPUInfo                             0x00007fff45e5fa61 _Z18getGPUFirmwareListv + 185
    8   vbiosupdater                        0x0000000105124a5a vbiosupdater + 27226
    9   vbiosupdater                        0x0000000105124f2b vbiosupdater + 28459
    10  libdyld.dylib                       0x00007fff34c84591 start + 1
  )

  2020-11-03 23:54:02.608 FirmwareUpdateLauncher[339:4521] Running /usr/libexec/vbiosupdater (
      "-p",
      "/Volumes/Update/softwareupdate.299.XrYyAw/source/boot/EFI",
      "-s"
  )
  2020-11-03 23:54:03.587 vbiosupdater[344:4528] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSTaggedPointerString substringWithRange:]: Range {0, 10} out of bounds; string length 7'
  *** First throw call stack:
  (
    0   CoreFoundation                      0x00007fff49274083 __exceptionPreprocess + 242
    1   libobjc.A.dylib                     0x00007fff48fab17c objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff49328c82 _CFThrowFormattedException + 194
    3   CoreFoundation                      0x00007fff493269f5 -[NSTaggedPointerString getBytes:maxLength:usedLength:encoding:options:range:remainingRange:].cold.1 + 0
    4   CoreFoundation                      0x00007fff491b8897 -[NSTaggedPointerString substringWithRange:] + 415
    5   vbiosupdater                        0x0000000102b3ccbe vbiosupdater + 19646
    6   vbiosupdater                        0x0000000102b3eafa vbiosupdater + 27386
    7   vbiosupdater                        0x0000000102b3ef2b vbiosupdater + 28459
    8   libdyld.dylib                       0x00007fff4911d591 start + 1
  )

• MultiUpdater is always added as BootNext and affects the following variables at most:

  # PciRoot(0x3)/Pci(0x0,0x0)/Pci(0x0,0x0)/SasEx(0x0100000000000000,0x000000007074616C,0x0,NoTopology,0,0,0)/HD(1,GPT,000001CF-8EE0-E676-6FC9-D5019E030000,0x800,0x18FFCD)/\EFI\APPLE\UPDATERS\MULTIUPDATER\MultiUpdater.efi
  8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0081
  8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootNext
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-boot-next-data
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-boot-next
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload0-data
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload0
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload1-data
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload1
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload2-data
  7C436110-AB2A-4BBB-A880-FE41995C9F82:efi-apple-payload2

[vit9696]

Based on this I believe we should:

• Always delete efi-boot-next-data and efi-boot-next on boot just as we do with BootNext.
• Introduce a quirk (probably BlacklistAppleUpdate) just as before that will ignore (and delete) BootNext entries containing EFI\APPLE as well as other related variables like efi-payloadX.
• Update notes about ATY,Rom# issues on dortania guides.

[vit9696]

Resolved by https://github.com/acidanthera/OpenCorePkg/commit/3998399ea941940f0a98b4c4172dcb46a85197a0.

[startergo]

• Interestingly, vbiosupdater is still broken and causes crashes when ATY,Rom# is a string instead of data OR has unexpected format. To fix that RX 5xxx owners should inject something like 123-456-789 via DeviceProperties. Last mentioned in #901.

I can't find such a property in my ioregistry with Orinoco framebuffer injection.

[vit9696]

And what?

[startergo]

Actually in my setup it is called:

ATY,EFIVersion 

And it corresponds to this in the Graphics/Display:

 EFI Driver Version:    01.01.183

My guess is it is the same property

[jacklukem]

Based on this I believe we should:

• Always delete efi-boot-next-data and efi-boot-next on boot just as we do with BootNext.
• Introduce a quirk (probably BlacklistAppleUpdate) just as before that will ignore (and delete) BootNext entries containing EFI\APPLE as well as other related variables like efi-payloadX.
• Update notes about ATY,Rom# issues on dortania guides.

Hello @vit9696 and @khronokernel , on EFI Mac through OC bootloader, about this recent run-efi-updater (NVRAM variable) issue encountered during the BigSur 11.0.1 staged installer I have three questions:

1) If I use a previous OC 0.5.9 where BlacklistAppleUpdate (Misc Security feature) was still available, would this skip eventually BigSur 11.0.1 unwanted EFI firmware update ?

2) About using OC 0.6.3 board id spoofing , since recently apple BootROM version are in the form of: xxxx.0.0.0.0 to skip the firmware update, would be possible on OC config for a BigSur installer (even using the problematic run-efi-updater), to spoof a fake BootROM with highest number example 9999.0.0.0.0 ?

3) Since apart the EFI BootROM firmware, there is also the SMC "firmware" in the form of an alphanumeric, does in general during a staged OSInstaller (or specifically on this newer BigSur "MobileAssets.zip") apple firmware packages (nvram firmware.scap) also checks for the SMC version to proceed with firmware update ?