SecureBootModel in OpenCore

[joserogo]

In normal daily use, is it better to boot with SecureBootModel = Disabled or with SecureBootModel = j174 (MacMini8,1)?

 

From what I have been able to understand in the Dortania guides, this parameter influences the verification of the integrity of the installed version of the operating system (and its updates), I do not know if it has any influence on the execution of the installed applications.

[joserogo]

Can anyone give me any opinion about it?

 

It might be that the question I have asked is completely absurd, I apologize for it, because I am still in the learning phase.

[Slice]

No, it influences nothing.

[verdazil]

The SecureBootModel parameter in the OpenCore settings is responsible for simulating the Secure Boot security system supported by Apple at the firmware level. It determines which Secure Boot identifier will be used to boot macOS. This affects compatibility with different versions of macOS and the operation of system updates.

 

SecureBootModel value options:
Disabled:

Secure Boot is disabled.
Suitable for systems where you need to boot older versions of macOS (for example, High Sierra or Mojave).
Can be useful for troubleshooting problems with incompatible hardware.
Default:

OpenCore automatically selects a Secure Boot model depending on the SystemProductName value (Mac model).
Usually used for modern macOS (Big Sur and newer).
Specific models (e.g. j137, j160, j185, etc.):

Specifies a specific Secure Boot identifier corresponding to a specific Mac model.
This can be useful for running macOS on hardware where you want to simulate a specific Mac model.

 

Impact on macOS:
Compatibility with System Integrity Protection (SIP):
The level of system security may depend on Secure Boot being enabled. Some features require Secure Boot support.

System updates:
Enabling Secure Boot may be required to download and install macOS updates.

Support for booting macOS Recovery and firmware:
Secure Boot may be required to successfully boot Recovery Mode and firmware updates.

Recommendations:
For older systems (e.g. macOS Mojave), it is recommended to leave SecureBootModel = Disabled.
For Big Sur, Monterey, or Sonoma, it is better to use Default to ensure that all features work correctly.
If the system requires a specific Mac model for installation or operation, select the corresponding identifier manually.

[cankiulascmnfye]

9 hours ago, verdazil said:

The SecureBootModel parameter in the OpenCore settings is responsible for simulating the Secure Boot security system supported by Apple at the firmware level. It determines which Secure Boot identifier will be used to boot macOS. This affects compatibility with different versions of macOS and the operation of system updates.

 

SecureBootModel value options:
Disabled:

Secure Boot is disabled.
Suitable for systems where you need to boot older versions of macOS (for example, High Sierra or Mojave).
Can be useful for troubleshooting problems with incompatible hardware.
Default:

OpenCore automatically selects a Secure Boot model depending on the SystemProductName value (Mac model).
Usually used for modern macOS (Big Sur and newer).
Specific models (e.g. j137, j160, j185, etc.):

Specifies a specific Secure Boot identifier corresponding to a specific Mac model.
This can be useful for running macOS on hardware where you want to simulate a specific Mac model.

 

Impact on macOS:
Compatibility with System Integrity Protection (SIP):
The level of system security may depend on Secure Boot being enabled. Some features require Secure Boot support.

System updates:
Enabling Secure Boot may be required to download and install macOS updates.

Support for booting macOS Recovery and firmware:
Secure Boot may be required to successfully boot Recovery Mode and firmware updates.

Recommendations:
For older systems (e.g. macOS Mojave), it is recommended to leave SecureBootModel = Disabled.
For Big Sur, Monterey, or Sonoma, it is better to use Default to ensure that all features work correctly.
If the system requires a specific Mac model for installation or operation, select the corresponding identifier manually.

 

As far as system updates are concerned, SecureBootModel is not required for receiving updates when RestrictEvents.kext is present and combined with "revpatch=sbvmm" parameter!

 

Besides that: SecureBootModel stopped working properly after Sonoma 14.3 or 14.4 and needs to be disabled prior to installing updates - otherwise the system will crash early during install.

Edited November 26 by cankiulascmnfye

[Slice]

SecureBootModel on real Macs instructs chip T2 to make his secure job.

But Hackintosh has no T2. The setting is surplus.

[verdazil]

1 hour ago, Slice said:

SecureBootModel on real Macs instructs chip T2 to make his secure job.

But Hackintosh has no T2. The setting is surplus.

 

The SecureBootModel parameter in OpenCore applies to both genuine Apple hardware and Hackintosh systems. Its main purpose is to simulate the behavior of the security system used in real Macs so that macOS can successfully boot and operate correctly.

Genuine Apple hardware:
On real Macs, this parameter is completely meaningless, since Secure Boot is already built into the firmware of their T2 chips or Apple Silicon.
OpenCore is only used on genuine Macs when it is necessary to boot an unsupported version of macOS or use custom boot settings.
Hackintosh systems:
For Hackintosh, this parameter is especially important because:

macOS expects Secure Boot to be present:
Starting with macOS Catalina, Apple has tightened the checks at the bootloader level, and some versions of macOS may not boot without Secure Boot enabled.
Identifying the "Mac Model" (SystemProductName):
Enabling SecureBootModel can help the system "believe" that it is running on a real Mac with the proper Secure Boot, even if it is a Hackintosh.
Bypassing update restrictions:
Some macOS updates require Secure Boot to be enabled and the correct Mac ID, which is especially true for Big Sur, Monterey, and Sonoma.
Hackintosh specifics:
Not real security:
Secure Boot in OpenCore is not a real security system, like on a T2-chip Mac or Apple Silicon. It is just an emulation that helps macOS "think" that it is running in the right environment.

Older macOS versions (High Sierra, Mojave):

These systems do not use Secure Boot, and SecureBootModel can be left disabled.
Modern versions of macOS (Big Sur and newer):

If this option is disabled (Disabled), you may encounter an error when booting, updating, or accessing Recovery Mode.

Bottom Line:
This option is useful for both Hackintosh and original Macs when using OpenCore. On Hackintosh, it is critical for compatibility with modern macOS, while on original Macs it is only used in rare cases (for example, to boot an unsupported version of macOS).

Edited November 26 by verdazil

[Slice]

Since Sonoma SecureBootModel must be disabled.

[miliuco]

@verdazil

I think that you forget SecuereBootModel=x86legacy -> Macs without T2 chip and Virtual Machines (Minimum macOS 11.0.1). I set this value in my Hack with iMac19,1 SMBIOS (Ventura, Sonoma and Sequoia disks) since long time ago with no issue. RestrictEvents not needed. Updates notification and incremental updates work as expected. iMac19,1 SMBIOS doesn't have a T2 chip either. So, according to OpenCore configuration guide, x86legacy is the best choice for this kind of SMBIOS.
 

@Slice assertion is true since Apple Secure Boot appeared in macOS 10.13 on models with T2 chips. And Hacks don't have such chip.

 

Anyway, I don't see any problem with having SecureBootModel=Disabled in Hacks, the way macOS works won't change, not to mention that Clover has always had this setting and it has worked well. But I also don't see any problem with having a SecureBootModel other than Disabled, it's a way to have the Hack closer to a real Mac even if it's not exactly the same.

[Slice]

9 hours ago, miliuco said:

But I also don't see any problem with having a SecureBootModel other than Disabled, 

The Opencore makes some group Nvram variables according to SecureBootModel proposing they influence something. But no. They do nothing.

We can deceive old system like Ventura producing such variables so why it influences on Software Update. But Apple fixed the hole in Sonoma.

[mhaeuser]

On 11/26/2024 at 5:25 PM, Slice said:

SecureBootModel on real Macs instructs chip T2 to make his secure job.

But Hackintosh has no T2. The setting is surplus.

No, in fact, the core Secure Boot implementation does not involve T2 at all whatsoever. T2 is only required for attestation, which in traditional terminology is not part of Secure Boot, but complementing it (Apple groups them under the same umbrella, however). Setting SecureBootModel enables kernel authentication in older macOS versions (by efiboot; newer ones do this unconditionally) and efiboot authentication (by OC) for all of them. Together with OC Vault, UEFI Secure Boot and stuff like Boot Guard, it forms a perfectly valid Chain of Trust that does not require T2.

 

Please, for the love of God, finally stop commenting on matters you obviously have no idea about.

[Slice]

Fantasy. And why SecureBootModel must be disable in Sonoma and up?

[miliuco]

1 hour ago, Slice said:

And why SecureBootModel must be disable in Sonoma and up?

 

Not always, I have SecureBootModel=x86legacy on Sequoia with iMac19,1 (since first beta).

[mhaeuser]

3 hours ago, Slice said:

Fantasy. And why SecureBootModel must be disable in Sonoma and up?

That “fantasy” is implemented in OcAppleSecureBootLib. As always, I urge people to trust the developers of the code that you consume over a Copy&Paste warrior (or just read the code…).

 

Sonoma, I don’t know, maybe it fails due to attestation. You could have at least read my reply properly if you won’t read the code you consume.

[eSaF]

Following this conversation and also guilty of being part of the 'Copy and Paste' gang, I decided to do a little experiment on my machine which is based on a Mac Model 20,2.

Why??!!, Seemed a good idea at the time after upgrading CPU and Motherboard. I have SecureBootModel=Disabled as was recommended at the time.

 

After reading @mhaeuser and @miliuco posts, I changed the setting to j185 from Disabled, rebooted, cleaned NvRAM twice and hoped for the best.

The machine booted as normal with no noticeable drop in boot time so I can only surmise that I can now leave the SecureBootModel=j185 instead of Disabled.

 

I suppose the real test will come when updates to the OS are offered how this change will play out.

While I am here, is it possible to also disable the RestrictEvents.kext? Sorry for the dumb question, as I stated I am part of the 'Copy and Paste' gang plus the retention of knowledge gets quite hard for me in old age.

Cheers.

Spoiler

 

[Slice]

"OC Vault"?

I have to remind that it was me who implemented FileVault technology for hackintosh bootloader. It was Clover and then Vit9696 applied these codes to OC. "Copy&Paste"

[miliuco]

@eSaF

You can work without RestrictEvents but, as your model has T2 chip, you need RestrictEvents to be notified about software updates.

 

You can set a value of SecureBootModel other than Disabled, preferabily the value that matches the SMBIOS model. I set x86legacy since this is the right value for no T2 Macs (iMac19,1) and virtual machines.

I'm pretty sure that you know that SecureBootModel (imitating Apple Secure Boot in some way) only acts at boot time, checking the integrity of the macOS system you are booting. E.g: a macOS not authorized by Apple in any way doesn't boot with SecureBootModel other than Disabled.

This feature is useful too if you want to filter the macOS versions your PC will be allowed to boot from: you can set the model that only supports the macOS versions you need, and not the older ones. For example, j185 (iMac20,1) and j185f (iMac20,2) will filter 10.15.5 and older, x86legacy will filter 10.15 and older and so on.

 

Not so important but, to be precise, iMac20,2 is j185f.

 

Edited December 2 by miliuco
Typo

[mhaeuser]

4 hours ago, Slice said:

"OC Vault"?

https://github.com/acidanthera/OpenCorePkg/blob/9163821d812972705854c9b1117322b8d8eed5a2/Docs/Configuration.tex#L4683-L4755

 

4 hours ago, Slice said:

I have to remind that it was me who implemented FileVault technology for hackintosh bootloader. It was Clover and then Vit9696 applied these codes to OC.

Ignoring the fact that OC vaulting has nothing to do with FV2... Are you dense? Nothing about Clover FV2 worked on any machine prior to our efforts. Let me remind you of the initial thread for Clover support here: https://www.insanelymac.com/forum/topic/317290-filevault-2/

 

Out of the mentioned drivers, some are 100% RE'd and re-implemented by Vit, some by myself, some were half-half, HashServicesFix was by ath (and iirc savvas) and FirmwareVolume was augmented with all necessary RE results by myself. The only component that was in Clover that worked as-is was AppleImageCodec and iirc even there support was extended. The biggest roadblock was a bug in Clover that unconditionally stripped leading \ from paths, breaking Apple's RPS algorithm that was incorrectly emulated by Clover. OC did not even exist (and wasn't planned either) at the time and all the issues surrounding retrofitting Clover for stuff like FV2 and modern Recovery were the starting point for planning OC. Till and including that point in time, we tried to fix and extend Clover as main flagship boot solution. Calling moving our very own code, previously "donated" to Clover, to our new boot solution "Copy&Paste" is beyond ridiculous.

 

Despite the fact your claim is entirely off-topic, it is an insult to all contributors that you claim this was your work - out of the listed people, I'd be confident in saying your contributions were by far the least relevant, maybe even irrelevant. Your incoherency is shocking and your year-long, continuous stream of misinformation is a disgrace for this community. Now, please stop opening incoherent and fake cans of worms and just educate yourself for once. Details about SecureBootModel are here and the mere existence of 'x86legacy' should imply to any half-sane individual that Secure Boot is not strictly tied to T2: https://github.com/acidanthera/OpenCorePkg/blob/9163821d812972705854c9b1117322b8d8eed5a2/Docs/Configuration.tex#L4584-L4681

 

Edited December 2 by mhaeuser

[Slice]

17 hours ago, mhaeuser said:

Let me remind you of the initial thread for Clover support here: https://www.insanelymac.com/forum/topic/317290-filevault-2/

 

 

See date 28.10.2016 and compare with initial dialog. Sorry in Russian. You may translate with google. 

 

[mhaeuser]

I don't know whether this is a language barrier or a real-life parody, but your post translates exactly to my claims... Whatever, I guess.

 

[Slice]

Compile also the answer.

[mhaeuser]

14 hours ago, Slice said:

Compile also the answer.

Slice, I’m growing tired of spamming random people’s threads with you every time you have a power trip. I did translate the response (for myself, but not posted here), just I didn’t and still don’t see what it has to do with anything. Yes, Vit was just starting out with UEFI, what else is new? His first own driver (iirc AmiShim) was an unholy Frankenstein of my UsbKbDxe mod, as he didn’t know the EDK II build system (can probably be checked in some source control for whoever is bored). Still, the actual code was top-notch and even in the UEFI space he contributed more than either of us combined. The two things he posted - AppleKeyMap and FvOnFv2Thunk (or more specifically, the Apple EFI FV cursor images) - were indeed the missing pieces for generic support (the rest was stuff like AMI bugs, backend implementations, or tweaks). Yet, both didn’t work due to Clover’s path normalization bug I mentioned before, which we uncovered and fixed. Yes, bug, Clover’s behaviour was broken and thus actively broke efiboot, not “missing feature”.

 

The rest goes on as I previously explained and I still don’t see what you’re trying to tell anyone with these posts.