After reading the comments from my blog post about SoftRAID version 5.8.4, I realized that there was some confusion about Secure Boot and how it protects your Mac from malware. When using SoftRAID on macOS 10.15 Catalina, on a Mac with a T2 chip, a user must disable Secure Boot for the correct version of the SoftRAID driver to load.
Some users don’t want to disable Secure Boot because they believe it disables all malware protection on their Mac. This belief is not correct, and Apple labeling the setting for disabling Secure Boot as “No Security” in the Startup System Security application doesn’t help. Even when Secure Boot is disabled, the T2 chip in your Mac is still protecting all the files on the internal SSD.
Actually, Secure Boot only protects your Mac for less than 2 minutes after the white Apple logo appears on the screen during startup. After 2 minutes, Secure Boot offers no protection.
What is protecting your Mac from malware the entire time, is System Integrity Protection (SIP). SIP starts protecting your Mac when it first boots up and continues for as long as your Mac is running. SIP ensures that software that runs on your Mac is only from developers recognized by Apple. Starting with macOS 10.14.6, SIP also assures that the software has been previously checked for malware by Apple’s malware scanning servers.
In This Article:
- This post explains how macOS is protected from malware by Secure Boot and SIP and how they differ and why we require that you disable Secure Boot while running SoftRAID.
- It also describes why we think it is acceptable to disable Secure Boot but would never recommend that anyone disable SIP.
- Lastly, it goes over the upcoming changes in Macs with Apple silicon, which will ship later this year.
Secure Boot Explained:
Secure Boot is available only on Macs with T2 chips. As the name implies, it protects your Mac against malware infection at boot time (when your Mac is starting up). In fact, it ONLY protects your Mac at boot time. Two minutes later, Secure Boot stops safeguarding your Mac.
Secure Boot is designed to allow only drivers that Apple ships to be used for the startup volume. Starting with macOS 10.15, if a newer version of one of those drivers is installed on your startup volume, Secure Boot will load the older one from the macOS installer instead. Unfortunately, this policy of only loading the driver included in the macOS installer also affects drivers not used for the startup volume – it affects all drivers loaded in the first 2 minutes.
Apple has been shipping the SoftRAID driver as part of macOS for more than ten years. This allows users to connect a SoftRAID volume to their Mac and have the volume mount without first running an application to update the driver. SoftRAID has a reputation for being very responsive in providing bug fixes and enhancements when they are needed. So, we want to give users the ability to update their SoftRAID driver when a new release becomes available.
Unfortunately, this is where Secure Boot gets in the way. If a user has a Mac with a T2 chip, has Secure Boot enabled, and has their SoftRAID volume attached at startup time or connects it within the first 2 minutes, Secure Boot loads the older version of the SoftRAID driver included in the macOS installer. If they connect their SoftRAID volume more than 2 minutes after startup, then the correct, updated driver loads instead.
What is SIP?
Unlike Secure Boot, SIP (System Integrity Protection) is available on all Macs—even those without T2 chips. In addition, it’s always running, both when your Mac first starts up and when it has been on for days, weeks, or months. It even runs if you have Secure Boot disabled. SIP has many different features that protect your Mac from malware, but the two I want to describe here are code signing and code notarization. (Code signing was introduced in Mac OS X 10.8 and code notarization in macOS 10.14.6.)
Code Signatures
When a developer signs an application or other software, a block of cryptographic data is appended to the application. This data, called a code signature, is the cryptographic result of processing all the application pieces in conjunction with a unique, large number that the developer has received from Apple. This unique, large number is a closely guarded secret protected by the developer.
When you first run an application on your Mac, SIP recalculates the code signature and checks to ensure it is the same as the one appended to the application. If the code signatures are not identical, SIP knows that the application has been changed by someone other than the original developer. SIP then prevents macOS from running the app and tells you why it cannot be run.
Code signatures act like the tamper-evident seals on the bottle of aspirin. They don’t prevent anyone from opening the bottle before buying it – they just make it obvious that someone has opened it before you. You know not to use the aspirin when the bottle’s seal is broken because what’s inside may be something different from the aspirin put in it at the factory.
Code Notarization
Code notarization takes protection against malware one step further and works in conjunction with code signatures. When an application is notarized, the developer sends it to Apple’s security servers. These servers check the application for malware, and if it is malware-free, the software is signed by Apple. The signature that Apple generates is then returned to the developer, who then attaches it, and the code signature, to the application.
Just like the code signature, SIP also checks that the Apple signature is valid. If the Apple signature is missing or invalid, SIP knows that Apple’s security servers did not check the application for malware, and macOS will refuse to run the application.
Code notarization acts like the title company does when you sell your house. The title company searches for anyone who might claim they own your house. If they don’t find anyone, they certify that you are actually the owner, and then you can proceed with your house’s sale. Apple’s security servers act in the same way – they certify that a piece of software is safe to sell to users.
What we recommend:
We want to ensure that you are only running the latest version of the SoftRAID driver with all of the enhancements and fixes we have worked hard to develop and test. This means that if you are on a Mac with a T2 chip and running macOS 10.15, you must do one of the following to use the latest SoftRAID driver:
- Disable Secure Boot following these instructions
–or– - Disconnect your all SoftRAID disks after shutdown and reconnect them more than 2 minutes after your Mac starts up. You will have to disconnect your SoftRAID disks during every restart or shutdown, waiting the same 2 minutes after starting up before reconnecting them.
Changes in security on Macs with Apple silicon:
When Apple starts shipping Macs with Apple silicon, you will be able to run them in one of two modes: “Full Security” or “Reduced Security.” (Notice that they are no longer calling it “No Security.”) In Full Security mode, macOS will only load drivers into the kernel, which are written by Apple. It will not load any drivers by other developers.
If you want to load any additional drivers into the kernel, you will have to run your Mac in the “Reduced Security” mode. Unlike Secure Boot, this security restriction is in force all the time. If you run with Reduced Security on Macs with Apple silicon, you can load the drivers for your RAID array, the high power ports on your Thunderbolt dock, or your super-fast video card.
Ohh so i have to disable my secure boot to install saftraid driver but why
Great clarification — especially about the 2 minute delay and a glimpse at the future, thank you!
Thanks for the article, really my only intention was to make the 4 blade Accelsior act as one hard drive. So we can leave secure boot on after setting up the drive and my 8TB Accelsior 4M2 will continue to function as normal? I guess what I am asking is what benefit will having soft raid run give me? The drive checking function?
Thanks
Why you don’t want to use Secure Boot with your Accelsior 4M2
You can leave Secure Boot on after setting up your Accelsior 4M2 but you will encounter lower performance, especially after using the Accelsior for a while. This is the result how the blades on the Accelsior use TRIM, the command which allows the file system to tell the blades that space on the volume is no longer being used.
Like the AppleRAID driver, the version of the SoftRAID driver which gets installed by the macOS installer does not support TRIM. This is the version of the driver which will get loaded if you boot macOS 10.15 with secure boot enabled on a T2 Mac. We originally made this decision because some older SSDs have very poor performance with TRIM enabled.
Unlike the version which is included with the macOS installer, the version of the driver which gets installed by the SoftRAID application fully supports TRIM commands on all RAID levels. As far as I know, we are the only RAID solution, hardware or software, which supports TRIM on macOS. So if you have Secure Boot disabled, you will be using the version of the SoftRAID driver which fully supports TRIM.
Our testing of the Accesior 4M2 with TRIM enabled shows that there is a 10-20% increase in performance if you use TRIM commands. With TRIM enabled, the blades are able to maintain this high performance indefinitely. If you have TRIM disabled, the performance of the blades will decrease further the longer you use the blades.
We now realize that most of the SSDs which have decreased performance when TRIM is enabled are 3 – 5 years old. Therefore, the version of the SoftRAID driver which will be included in the installer for macOS 11, will be changed to have TRIM enabled.
Background on the TRIM command
The TRIM command allows the file system to tell a blade when a file has been deleted. The blade can then erase the blocks which were used for the file, in the background, while you are performing other tasks. Since erasing blocks on the blade is a relatively slow process, the blade can perform this operation in advance and always have erased blocks available to accommodate new file data which you want to write. (Flash memory chips in blades cannot be written to unless they are first erased.)
If TRIM commands are not used, there are times when the drive must erase blocks right before they are written to. This occurs most often when you are writing large amounts of data to a blade. If a set of blocks must be erased before they are written to, then the time required for the write command is the sum of the erase time and as well as the write time. This can be as much as 3 times longer than the time required to write to blocks that are already erased. This is why the TRIM commands are so important.