"TT_PowerTimeoutKernelPanic" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.15 (not required for older)\nDescription: Disables kernel panic on setPowerState timeout.\nAn additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up. For debug kernels setpowerstate_panic=0 boot argument should be used, which is otherwise equivalent to this quirk.";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n• For KVM and other hypervisors it provides precomputed MSR 35h values solving kernel panic with -cpu host.\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
/* yhV-cY-frg */
"TT_ThirdPartyDrives" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.6 (not required for older)\nDescription: Apply vendor patches to IOAHCIBlockStorage.kext to enable native features for third-party drives, such as TRIM on SSDs or hibernation support on 10.15 and newer.\nNote: This option may be avoided on user preference. NVMe SSDs are compatible without the change. For AHCI SSDs on modern macOS version there is a dedicated built-in utility called trimforce. Starting from 10.15 this utility creates EnableTRIM variable in APPLE_BOOT_VARIABLE_GUID namespace with 01 00 00 00 value.";
...
...
@@ -1122,7 +1122,7 @@
"TT_XhciPortLimit" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.11 (not required for older)\nDescription: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.\n\nNote: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some).";
/* Ot6-tN-JLe */
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
/* miscController */
/* Boot */
...
...
@@ -1201,7 +1201,7 @@
"TT_scanpolicy" = "Type: plist integer, 32 bit\nFailsafe: 0x10F0103\nDescription: Define operating system detection policy.\n\nThis value allows preventing scanning (and booting) untrusted sources based on a bitmask (sum) of a set of flags. As it is not possible to reliably detect every file system or device type, this feature cannot be fully relied upon in open environments, and additional measures are to be applied.\n\nThird party drivers may introduce additional security (and performance) consideratons following the provided scan policy. The active Scan policy is exposed in the scan-policy variable of 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID for UEFI Boot Services only.\n• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.\n• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported.\nKnown device types are prefixed with OC_SCAN_ALLOW_DEVICE_.\n• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.\n• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.\n• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.\n• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.\n• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.\n• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.\n• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition as defined by the Boot Loader Specification.\n• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.\n• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.\n• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.\n• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.\n• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.\n• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.\n• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.\n• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.\n• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus (e.g. VIRTIO).\n\nNote: Given the above description, a value of 0xF0103 is expected to do the following:\n• Permit scanning SATA, SAS, SCSI, and NVMe devices with APFS file systems.\n• Prevent scanning any devices with HFS or FAT32 file systems.\n• Prevent scanning APFS file systems on USB, CD, and FireWire drives.\n\nThe combination reads as:\n• OC_SCAN_FILE_SYSTEM_LOCK\n• OC_SCAN_DEVICE_LOCK\n• OC_SCAN_ALLOW_FS_APFS\n• OC_SCAN_ALLOW_DEVICE_SATA\n• OC_SCAN_ALLOW_DEVICE_SASEX\n• OC_SCAN_ALLOW_DEVICE_SCSI\n• OC_SCAN_ALLOW_DEVICE_NVME";
/* 0yA-ct-dgi */
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Unless the operating system is personalised, macOS DMG recovery cannot be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Until the operating system is personalised, only macOS DMG recovery can be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
/* QZk-2b-TCx */
"TT_vault" = "Type: plist string\nFailsafe: Secure\nDescription: Enables the OpenCore vaulting mechanism.\nValid values:\n• Optional — require nothing, no vault is enforced, insecure.\n• Basic — require vault.plist file present in OC directory. This provides basic filesystem integrity verification and may protect from unintentional filesystem corruption.\n• Secure — require vault.sig signature file for vault.plist in OC directory. This includes Basic integrity checking but also attempts to build a trusted bootchain.\n\nThe vault.plist file should contain SHA-256 hashes for all files used by OpenCore. The presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not go unnoticed. To create this file automatically, use the create_vault.sh script. Notwithstanding the underlying file system, the path names and cases between config.plist and vault.plist must match.\n\nThe vault.sig file should contain a raw 256 byte RSA-2048 signature from a SHA-256 hash of vault.plist. The signature is verified against the public key embedded into OpenCore.efi.\n\nTo embed the public key, either one of the following should be performed:\n• Provide public key during the OpenCore.efi compilation in OpenCoreVault.c file.\n• Binary patch OpenCore.efi replacing zeroes with the public key between =BEGIN OC VAULT= and ==END OC VAULT== ASCII markers.\n\nThe RSA public key 520 byte format description can be found in Chromium OS documentation. To convert the\npublic key from X.509 certificate or from PEM file use RsaTool.\n\nThe complete set of commands to:\n• Create vault.plist.\n• Create a new RSA key (always do this to avoid loading old configuration).\n• Embed RSA key into OpenCore.efi.\n• Create vault.sig.\n\nCan look as follows:\ncd /Volumes/EFI/EFI/OC/path/to/create_vault.sh .\n/path/to/RsaTool -sign vault.plist vault.sig vault.pub\noff=$(($(strings -a -t d OpenCore.efi | grep \"=BEGIN OC VAULT=\" | cut -f1 -d' ')+16))\ndd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=528 conv=notrunc\nrm vault.pub\n\nNote 1: While it may appear obvious, an external method is required to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this, it is recommended to enable UEFI SecureBoot using a custom certificate and to sign OpenCore.efi and BOOTx64.efi with a custom key. More details on customising secure boot on modern firmware can be found in the Taming UEFI SecureBoot paper (in Russian).\n\nNote 2: Regardless of this option, vault.plist is always used when present, and both vault.plist and vault.sig are used and required when a public key is embedded into OpenCore.efi, and errors will abort the boot process in either case. Setting this option allows OpenCore to warn the user if the configuration is not as required to achieve an expected higher security level.";
"TT_PowerTimeoutKernelPanic" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.15 (not required for older)\nDescription: Disables kernel panic on setPowerState timeout.\nAn additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up. For debug kernels setpowerstate_panic=0 boot argument should be used, which is otherwise equivalent to this quirk.";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n• For KVM and other hypervisors it provides precomputed MSR 35h values solving kernel panic with -cpu host.\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
/* yhV-cY-frg */
"TT_ThirdPartyDrives" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.6 (not required for older)\nDescription: Apply vendor patches to IOAHCIBlockStorage.kext to enable native features for third-party drives, such as TRIM on SSDs or hibernation support on 10.15 and newer.\nNote: This option may be avoided on user preference. NVMe SSDs are compatible without the change. For AHCI SSDs on modern macOS version there is a dedicated built-in utility called trimforce. Starting from 10.15 this utility creates EnableTRIM variable in APPLE_BOOT_VARIABLE_GUID namespace with 01 00 00 00 value.";
...
...
@@ -1122,7 +1122,7 @@
"TT_XhciPortLimit" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.11 (not required for older)\nDescription: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.\n\nNote: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some).";
/* Ot6-tN-JLe */
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
/* miscController */
/* Boot */
...
...
@@ -1201,7 +1201,7 @@
"TT_scanpolicy" = "Type: plist integer, 32 bit\nFailsafe: 0x10F0103\nDescription: Define operating system detection policy.\n\nThis value allows preventing scanning (and booting) untrusted sources based on a bitmask (sum) of a set of flags. As it is not possible to reliably detect every file system or device type, this feature cannot be fully relied upon in open environments, and additional measures are to be applied.\n\nThird party drivers may introduce additional security (and performance) consideratons following the provided scan policy. The active Scan policy is exposed in the scan-policy variable of 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID for UEFI Boot Services only.\n• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.\n• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported.\nKnown device types are prefixed with OC_SCAN_ALLOW_DEVICE_.\n• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.\n• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.\n• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.\n• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.\n• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.\n• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.\n• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition as defined by the Boot Loader Specification.\n• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.\n• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.\n• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.\n• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.\n• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.\n• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.\n• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.\n• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.\n• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus (e.g. VIRTIO).\n\nNote: Given the above description, a value of 0xF0103 is expected to do the following:\n• Permit scanning SATA, SAS, SCSI, and NVMe devices with APFS file systems.\n• Prevent scanning any devices with HFS or FAT32 file systems.\n• Prevent scanning APFS file systems on USB, CD, and FireWire drives.\n\nThe combination reads as:\n• OC_SCAN_FILE_SYSTEM_LOCK\n• OC_SCAN_DEVICE_LOCK\n• OC_SCAN_ALLOW_FS_APFS\n• OC_SCAN_ALLOW_DEVICE_SATA\n• OC_SCAN_ALLOW_DEVICE_SASEX\n• OC_SCAN_ALLOW_DEVICE_SCSI\n• OC_SCAN_ALLOW_DEVICE_NVME";
/* 0yA-ct-dgi */
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Unless the operating system is personalised, macOS DMG recovery cannot be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Until the operating system is personalised, only macOS DMG recovery can be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
/* QZk-2b-TCx */
"TT_vault" = "Type: plist string\nFailsafe: Secure\nDescription: Enables the OpenCore vaulting mechanism.\nValid values:\n• Optional — require nothing, no vault is enforced, insecure.\n• Basic — require vault.plist file present in OC directory. This provides basic filesystem integrity verification and may protect from unintentional filesystem corruption.\n• Secure — require vault.sig signature file for vault.plist in OC directory. This includes Basic integrity checking but also attempts to build a trusted bootchain.\n\nThe vault.plist file should contain SHA-256 hashes for all files used by OpenCore. The presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not go unnoticed. To create this file automatically, use the create_vault.sh script. Notwithstanding the underlying file system, the path names and cases between config.plist and vault.plist must match.\n\nThe vault.sig file should contain a raw 256 byte RSA-2048 signature from a SHA-256 hash of vault.plist. The signature is verified against the public key embedded into OpenCore.efi.\n\nTo embed the public key, either one of the following should be performed:\n• Provide public key during the OpenCore.efi compilation in OpenCoreVault.c file.\n• Binary patch OpenCore.efi replacing zeroes with the public key between =BEGIN OC VAULT= and ==END OC VAULT== ASCII markers.\n\nThe RSA public key 520 byte format description can be found in Chromium OS documentation. To convert the\npublic key from X.509 certificate or from PEM file use RsaTool.\n\nThe complete set of commands to:\n• Create vault.plist.\n• Create a new RSA key (always do this to avoid loading old configuration).\n• Embed RSA key into OpenCore.efi.\n• Create vault.sig.\n\nCan look as follows:\ncd /Volumes/EFI/EFI/OC/path/to/create_vault.sh .\n/path/to/RsaTool -sign vault.plist vault.sig vault.pub\noff=$(($(strings -a -t d OpenCore.efi | grep \"=BEGIN OC VAULT=\" | cut -f1 -d' ')+16))\ndd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=528 conv=notrunc\nrm vault.pub\n\nNote 1: While it may appear obvious, an external method is required to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this, it is recommended to enable UEFI SecureBoot using a custom certificate and to sign OpenCore.efi and BOOTx64.efi with a custom key. More details on customising secure boot on modern firmware can be found in the Taming UEFI SecureBoot paper (in Russian).\n\nNote 2: Regardless of this option, vault.plist is always used when present, and both vault.plist and vault.sig are used and required when a public key is embedded into OpenCore.efi, and errors will abort the boot process in either case. Setting this option allows OpenCore to warn the user if the configuration is not as required to achieve an expected higher security level.";
"TT_PowerTimeoutKernelPanic" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.15 (not required for older)\nDescription: Disables kernel panic on setPowerState timeout.\nAn additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up. For debug kernels setpowerstate_panic=0 boot argument should be used, which is otherwise equivalent to this quirk.";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n• For KVM and other hypervisors it provides precomputed MSR 35h values solving kernel panic with -cpu host.\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
/* yhV-cY-frg */
"TT_ThirdPartyDrives" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.6 (not required for older)\nDescription: Apply vendor patches to IOAHCIBlockStorage.kext to enable native features for third-party drives, such as TRIM on SSDs or hibernation support on 10.15 and newer.\nNote: This option may be avoided on user preference. NVMe SSDs are compatible without the change. For AHCI SSDs on modern macOS version there is a dedicated built-in utility called trimforce. Starting from 10.15 this utility creates EnableTRIM variable in APPLE_BOOT_VARIABLE_GUID namespace with 01 00 00 00 value.";
...
...
@@ -1122,7 +1122,7 @@
"TT_XhciPortLimit" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.11 (not required for older)\nDescription: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.\n\nNote: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some).";
/* Ot6-tN-JLe */
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
/* miscController */
/* Boot */
...
...
@@ -1201,7 +1201,7 @@
"TT_scanpolicy" = "Type: plist integer, 32 bit\nFailsafe: 0x10F0103\nDescription: Define operating system detection policy.\n\nThis value allows preventing scanning (and booting) untrusted sources based on a bitmask (sum) of a set of flags. As it is not possible to reliably detect every file system or device type, this feature cannot be fully relied upon in open environments, and additional measures are to be applied.\n\nThird party drivers may introduce additional security (and performance) consideratons following the provided scan policy. The active Scan policy is exposed in the scan-policy variable of 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID for UEFI Boot Services only.\n• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.\n• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported.\nKnown device types are prefixed with OC_SCAN_ALLOW_DEVICE_.\n• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.\n• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.\n• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.\n• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.\n• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.\n• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.\n• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition as defined by the Boot Loader Specification.\n• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.\n• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.\n• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.\n• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.\n• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.\n• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.\n• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.\n• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.\n• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus (e.g. VIRTIO).\n\nNote: Given the above description, a value of 0xF0103 is expected to do the following:\n• Permit scanning SATA, SAS, SCSI, and NVMe devices with APFS file systems.\n• Prevent scanning any devices with HFS or FAT32 file systems.\n• Prevent scanning APFS file systems on USB, CD, and FireWire drives.\n\nThe combination reads as:\n• OC_SCAN_FILE_SYSTEM_LOCK\n• OC_SCAN_DEVICE_LOCK\n• OC_SCAN_ALLOW_FS_APFS\n• OC_SCAN_ALLOW_DEVICE_SATA\n• OC_SCAN_ALLOW_DEVICE_SASEX\n• OC_SCAN_ALLOW_DEVICE_SCSI\n• OC_SCAN_ALLOW_DEVICE_NVME";
/* 0yA-ct-dgi */
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Unless the operating system is personalised, macOS DMG recovery cannot be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Until the operating system is personalised, only macOS DMG recovery can be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
/* QZk-2b-TCx */
"TT_vault" = "Type: plist string\nFailsafe: Secure\nDescription: Enables the OpenCore vaulting mechanism.\nValid values:\n• Optional — require nothing, no vault is enforced, insecure.\n• Basic — require vault.plist file present in OC directory. This provides basic filesystem integrity verification and may protect from unintentional filesystem corruption.\n• Secure — require vault.sig signature file for vault.plist in OC directory. This includes Basic integrity checking but also attempts to build a trusted bootchain.\n\nThe vault.plist file should contain SHA-256 hashes for all files used by OpenCore. The presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not go unnoticed. To create this file automatically, use the create_vault.sh script. Notwithstanding the underlying file system, the path names and cases between config.plist and vault.plist must match.\n\nThe vault.sig file should contain a raw 256 byte RSA-2048 signature from a SHA-256 hash of vault.plist. The signature is verified against the public key embedded into OpenCore.efi.\n\nTo embed the public key, either one of the following should be performed:\n• Provide public key during the OpenCore.efi compilation in OpenCoreVault.c file.\n• Binary patch OpenCore.efi replacing zeroes with the public key between =BEGIN OC VAULT= and ==END OC VAULT== ASCII markers.\n\nThe RSA public key 520 byte format description can be found in Chromium OS documentation. To convert the\npublic key from X.509 certificate or from PEM file use RsaTool.\n\nThe complete set of commands to:\n• Create vault.plist.\n• Create a new RSA key (always do this to avoid loading old configuration).\n• Embed RSA key into OpenCore.efi.\n• Create vault.sig.\n\nCan look as follows:\ncd /Volumes/EFI/EFI/OC/path/to/create_vault.sh .\n/path/to/RsaTool -sign vault.plist vault.sig vault.pub\noff=$(($(strings -a -t d OpenCore.efi | grep \"=BEGIN OC VAULT=\" | cut -f1 -d' ')+16))\ndd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=528 conv=notrunc\nrm vault.pub\n\nNote 1: While it may appear obvious, an external method is required to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this, it is recommended to enable UEFI SecureBoot using a custom certificate and to sign OpenCore.efi and BOOTx64.efi with a custom key. More details on customising secure boot on modern firmware can be found in the Taming UEFI SecureBoot paper (in Russian).\n\nNote 2: Regardless of this option, vault.plist is always used when present, and both vault.plist and vault.sig are used and required when a public key is embedded into OpenCore.efi, and errors will abort the boot process in either case. Setting this option allows OpenCore to warn the user if the configuration is not as required to achieve an expected higher security level.";
"TT_PowerTimeoutKernelPanic" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.15 (not required for older)\nDescription: Disables kernel panic on setPowerState timeout.\nAn additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up. For debug kernels setpowerstate_panic=0 boot argument should be used, which is otherwise equivalent to this quirk.";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n• For KVM and other hypervisors it provides precomputed MSR 35h values solving kernel panic with -cpu host.\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
/* yhV-cY-frg */
"TT_ThirdPartyDrives" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.6 (not required for older)\nDescription: Apply vendor patches to IOAHCIBlockStorage.kext to enable native features for third-party drives, such as TRIM on SSDs or hibernation support on 10.15 and newer.\nNote: This option may be avoided on user preference. NVMe SSDs are compatible without the change. For AHCI SSDs on modern macOS version there is a dedicated built-in utility called trimforce. Starting from 10.15 this utility creates EnableTRIM variable in APPLE_BOOT_VARIABLE_GUID namespace with 01 00 00 00 value.";
...
...
@@ -1122,7 +1122,7 @@
"TT_XhciPortLimit" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.11 (not required for older)\nDescription: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.\n\nNote: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some).";
/* Ot6-tN-JLe */
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
/* miscController */
/* Boot */
...
...
@@ -1201,7 +1201,7 @@
"TT_scanpolicy" = "Type: plist integer, 32 bit\nFailsafe: 0x10F0103\nDescription: Define operating system detection policy.\n\nThis value allows preventing scanning (and booting) untrusted sources based on a bitmask (sum) of a set of flags. As it is not possible to reliably detect every file system or device type, this feature cannot be fully relied upon in open environments, and additional measures are to be applied.\n\nThird party drivers may introduce additional security (and performance) consideratons following the provided scan policy. The active Scan policy is exposed in the scan-policy variable of 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID for UEFI Boot Services only.\n• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.\n• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported.\nKnown device types are prefixed with OC_SCAN_ALLOW_DEVICE_.\n• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.\n• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.\n• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.\n• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.\n• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.\n• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.\n• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition as defined by the Boot Loader Specification.\n• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.\n• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.\n• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.\n• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.\n• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.\n• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.\n• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.\n• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.\n• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus (e.g. VIRTIO).\n\nNote: Given the above description, a value of 0xF0103 is expected to do the following:\n• Permit scanning SATA, SAS, SCSI, and NVMe devices with APFS file systems.\n• Prevent scanning any devices with HFS or FAT32 file systems.\n• Prevent scanning APFS file systems on USB, CD, and FireWire drives.\n\nThe combination reads as:\n• OC_SCAN_FILE_SYSTEM_LOCK\n• OC_SCAN_DEVICE_LOCK\n• OC_SCAN_ALLOW_FS_APFS\n• OC_SCAN_ALLOW_DEVICE_SATA\n• OC_SCAN_ALLOW_DEVICE_SASEX\n• OC_SCAN_ALLOW_DEVICE_SCSI\n• OC_SCAN_ALLOW_DEVICE_NVME";
/* 0yA-ct-dgi */
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Unless the operating system is personalised, macOS DMG recovery cannot be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Until the operating system is personalised, only macOS DMG recovery can be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
/* QZk-2b-TCx */
"TT_vault" = "Type: plist string\nFailsafe: Secure\nDescription: Enables the OpenCore vaulting mechanism.\nValid values:\n• Optional — require nothing, no vault is enforced, insecure.\n• Basic — require vault.plist file present in OC directory. This provides basic filesystem integrity verification and may protect from unintentional filesystem corruption.\n• Secure — require vault.sig signature file for vault.plist in OC directory. This includes Basic integrity checking but also attempts to build a trusted bootchain.\n\nThe vault.plist file should contain SHA-256 hashes for all files used by OpenCore. The presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not go unnoticed. To create this file automatically, use the create_vault.sh script. Notwithstanding the underlying file system, the path names and cases between config.plist and vault.plist must match.\n\nThe vault.sig file should contain a raw 256 byte RSA-2048 signature from a SHA-256 hash of vault.plist. The signature is verified against the public key embedded into OpenCore.efi.\n\nTo embed the public key, either one of the following should be performed:\n• Provide public key during the OpenCore.efi compilation in OpenCoreVault.c file.\n• Binary patch OpenCore.efi replacing zeroes with the public key between =BEGIN OC VAULT= and ==END OC VAULT== ASCII markers.\n\nThe RSA public key 520 byte format description can be found in Chromium OS documentation. To convert the\npublic key from X.509 certificate or from PEM file use RsaTool.\n\nThe complete set of commands to:\n• Create vault.plist.\n• Create a new RSA key (always do this to avoid loading old configuration).\n• Embed RSA key into OpenCore.efi.\n• Create vault.sig.\n\nCan look as follows:\ncd /Volumes/EFI/EFI/OC/path/to/create_vault.sh .\n/path/to/RsaTool -sign vault.plist vault.sig vault.pub\noff=$(($(strings -a -t d OpenCore.efi | grep \"=BEGIN OC VAULT=\" | cut -f1 -d' ')+16))\ndd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=528 conv=notrunc\nrm vault.pub\n\nNote 1: While it may appear obvious, an external method is required to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this, it is recommended to enable UEFI SecureBoot using a custom certificate and to sign OpenCore.efi and BOOTx64.efi with a custom key. More details on customising secure boot on modern firmware can be found in the Taming UEFI SecureBoot paper (in Russian).\n\nNote 2: Regardless of this option, vault.plist is always used when present, and both vault.plist and vault.sig are used and required when a public key is embedded into OpenCore.efi, and errors will abort the boot process in either case. Setting this option allows OpenCore to warn the user if the configuration is not as required to achieve an expected higher security level.";
"TT_PowerTimeoutKernelPanic" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.15 (not required for older)\nDescription: Disables kernel panic on setPowerState timeout.\nAn additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up. For debug kernels setpowerstate_panic=0 boot argument should be used, which is otherwise equivalent to this quirk.";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
"TT_ProvideCurrentCpuInfo" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.8 (10.14)\nDescription: Provides current CPU info to the kernel.\n\nThis quirk works differently depending on the CPU:\n• For Microsoft Hyper-V it provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+).\n• For KVM and other hypervisors it provides precomputed MSR 35h values solving kernel panic with -cpu host.\n• For Intel CPUs it adds support for asymmetrical SMP systems (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+).";
/* yhV-cY-frg */
"TT_ThirdPartyDrives" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.6 (not required for older)\nDescription: Apply vendor patches to IOAHCIBlockStorage.kext to enable native features for third-party drives, such as TRIM on SSDs or hibernation support on 10.15 and newer.\nNote: This option may be avoided on user preference. NVMe SSDs are compatible without the change. For AHCI SSDs on modern macOS version there is a dedicated built-in utility called trimforce. Starting from 10.15 this utility creates EnableTRIM variable in APPLE_BOOT_VARIABLE_GUID namespace with 01 00 00 00 value.";
...
...
@@ -1122,7 +1122,7 @@
"TT_XhciPortLimit" = "Type: plist boolean\nFailsafe: false\nRequirement: 10.11 (not required for older)\nDescription: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.\n\nNote: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some).";
/* Ot6-tN-JLe */
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
"TT_SetApfsTrimTimeout" = "Type: plist integer\nFailsafe: -1\nRequirement: 10.14 (not required for older)\nDescription: Set trim timeout in microseconds for APFS filesystems on SSDs.\n\nThe APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.\nDepending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.\nOn several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.\nOne way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999.\n\nAs of macOS 12.0+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.";
/* miscController */
/* Boot */
...
...
@@ -1201,7 +1201,7 @@
"TT_scanpolicy" = "Type: plist integer, 32 bit\nFailsafe: 0x10F0103\nDescription: Define operating system detection policy.\n\nThis value allows preventing scanning (and booting) untrusted sources based on a bitmask (sum) of a set of flags. As it is not possible to reliably detect every file system or device type, this feature cannot be fully relied upon in open environments, and additional measures are to be applied.\n\nThird party drivers may introduce additional security (and performance) consideratons following the provided scan policy. The active Scan policy is exposed in the scan-policy variable of 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 GUID for UEFI Boot Services only.\n• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.\n• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported.\nKnown device types are prefixed with OC_SCAN_ALLOW_DEVICE_.\n• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.\n• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.\n• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.\n• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.\n• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.\n• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.\n• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition as defined by the Boot Loader Specification.\n• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.\n• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.\n• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.\n• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.\n• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.\n• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.\n• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.\n• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.\n• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus (e.g. VIRTIO).\n\nNote: Given the above description, a value of 0xF0103 is expected to do the following:\n• Permit scanning SATA, SAS, SCSI, and NVMe devices with APFS file systems.\n• Prevent scanning any devices with HFS or FAT32 file systems.\n• Prevent scanning APFS file systems on USB, CD, and FireWire drives.\n\nThe combination reads as:\n• OC_SCAN_FILE_SYSTEM_LOCK\n• OC_SCAN_DEVICE_LOCK\n• OC_SCAN_ALLOW_FS_APFS\n• OC_SCAN_ALLOW_DEVICE_SATA\n• OC_SCAN_ALLOW_DEVICE_SASEX\n• OC_SCAN_ALLOW_DEVICE_SCSI\n• OC_SCAN_ALLOW_DEVICE_NVME";
/* 0yA-ct-dgi */
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Unless the operating system is personalised, macOS DMG recovery cannot be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
"TT_ApECID" = "Type: plist integer, 64 bit\nFailsafe: 0\nDescription: Apple Enclave Identifier.\n\nSetting this value to any non-zero 64-bit integer will allow using personalised Apple Secure Boot identifiers. To use this setting, generate a random 64-bit number with a cryptographically secure random number generator. As an alternative, the first 8 bytes of SystemUUID can be used for ApECID, this is found in macOS 11 for Macs without the T2 chip.\n\nWith this value set and SecureBootModel valid (and not Disabled), it is possible to achieve Full Security of Apple Secure Boot.\n\nTo start using personalised Apple Secure Boot, the operating system must be reinstalled or personalised. Until the operating system is personalised, only macOS DMG recovery can be loaded. In cases where DMG recovery is missing, it can be downloaded by using the macrecovery utility and saved in com.apple.recovery.boot as explained in the Tips and Tricks section. Note that DMG loading needs to be set to Signed to use any DMG with Apple Secure Boot.\n\nTo personalise an existing operating system, use the bless command after loading to macOS DMG recovery. Mount the system volume partition, unless it has already been mounted, and execute the following command:\nbless bless --folder \"/Volumes/Macintosh HD/System/Library/CoreServices\" \\ --bootefi --personalize\n\nOn macOS 11 and newer the dedicated x86legacy model always uses ApECID. When this configuration setting is left as 0 first 8 bytes of system-id variable are used instead.\n\nOn macOS versions before macOS 11, which introduced a dedicated x86legacy model for models without the T2 chip, personalised Apple Secure Boot may not work as expected. When reinstalling the operating system, the macOS Installer from macOS 10.15 and older will often run out of free memory on the /var/tmp partition when trying to install macOS with the personalised Apple Secure Boot. Soon after downloading the macOS installer image, an Unable to verify macOS error message will appear.\n\nTo workaround this issue, allocate a dedicated RAM disk of 2 MBs for macOS personalisation by entering the following commands in the macOS recovery terminal before starting the installation:\ndisk=$(hdiutil attach -nomount ram://4096)\ndiskutil erasevolume HFS+ SecureBoot $disk\ndiskutil unmount $disk\nmkdir /var/tmp/OSPersonalizationTemp\ndiskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk";
/* QZk-2b-TCx */
"TT_vault" = "Type: plist string\nFailsafe: Secure\nDescription: Enables the OpenCore vaulting mechanism.\nValid values:\n• Optional — require nothing, no vault is enforced, insecure.\n• Basic — require vault.plist file present in OC directory. This provides basic filesystem integrity verification and may protect from unintentional filesystem corruption.\n• Secure — require vault.sig signature file for vault.plist in OC directory. This includes Basic integrity checking but also attempts to build a trusted bootchain.\n\nThe vault.plist file should contain SHA-256 hashes for all files used by OpenCore. The presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not go unnoticed. To create this file automatically, use the create_vault.sh script. Notwithstanding the underlying file system, the path names and cases between config.plist and vault.plist must match.\n\nThe vault.sig file should contain a raw 256 byte RSA-2048 signature from a SHA-256 hash of vault.plist. The signature is verified against the public key embedded into OpenCore.efi.\n\nTo embed the public key, either one of the following should be performed:\n• Provide public key during the OpenCore.efi compilation in OpenCoreVault.c file.\n• Binary patch OpenCore.efi replacing zeroes with the public key between =BEGIN OC VAULT= and ==END OC VAULT== ASCII markers.\n\nThe RSA public key 520 byte format description can be found in Chromium OS documentation. To convert the\npublic key from X.509 certificate or from PEM file use RsaTool.\n\nThe complete set of commands to:\n• Create vault.plist.\n• Create a new RSA key (always do this to avoid loading old configuration).\n• Embed RSA key into OpenCore.efi.\n• Create vault.sig.\n\nCan look as follows:\ncd /Volumes/EFI/EFI/OC/path/to/create_vault.sh .\n/path/to/RsaTool -sign vault.plist vault.sig vault.pub\noff=$(($(strings -a -t d OpenCore.efi | grep \"=BEGIN OC VAULT=\" | cut -f1 -d' ')+16))\ndd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=528 conv=notrunc\nrm vault.pub\n\nNote 1: While it may appear obvious, an external method is required to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this, it is recommended to enable UEFI SecureBoot using a custom certificate and to sign OpenCore.efi and BOOTx64.efi with a custom key. More details on customising secure boot on modern firmware can be found in the Taming UEFI SecureBoot paper (in Russian).\n\nNote 2: Regardless of this option, vault.plist is always used when present, and both vault.plist and vault.sig are used and required when a public key is embedded into OpenCore.efi, and errors will abort the boot process in either case. Setting this option allows OpenCore to warn the user if the configuration is not as required to achieve an expected higher security level.";
