Seems like you could install the kext to the internal drive, then use a tool like Carbon Copy Cloner to build a bootable external copy of the internal system with the kext installed.
I have Monterey running on an external Samsung drive on my M1.
However I've found it difficult to do this with my older Intel laptop specifically with Monterey though I have used Catalina as an external drive on the Intel MacBook. I have an external drive with Windows for the Intel MacBook as well.
I don't really have a lot of insight to offer despite this being my standard MO on most machines.
Running from an external drive is a great way to operate -- even though it seems like an unnecessary step it offers a lot of flexibility and would encourage others to familiarize themselves with the practice even if you opt for internal drives.
This tweet has made the rounds, but it’s wrong in its claims about Secure Boot. Your claim that protection against physical presence is novel to ARM Apple devices is also mistaken. See my comments in a previous thread:
Extracting the relevant bits and cleaning them up:
Macs/iOS devices and PCs—through the Secure Enclave and TPM/Secure Boot/Bitlocker, respectively—offer really good protection against physical access attacks. They verify the integrity of boot components and are only able to decrypt the system volume if they detect an untampered boot chain. Further, they can lock down direct memory access to protect powered-on systems from bypasses to user authentication. This is why nowadays, if a thief steals your laptop and you had the hard drive encryption with hardware security features on (on Windows, if you set up with a Microsoft Account, this is enabled without any further action by the user), you can feel fairly secure that even a technically savvy thief cannot access your data.
And:
This tweet is wrong when it claims that Secure Boot does not protect against physical presence attacks. This misunderstands the point of Secure Boot.
Secure Boot can indeed be disabled, but that will change the TPM PCR values, so assuming a standard BitLocker configuration, the TPM will fail to unlock the BitLocker key. So if you try to disable Secure Boot on such a machine, you will be unable to boot or otherwise access that volume (even with another machine) unless you have the BitLocker recovery key.
False. Windows Home does not come with encryption, Windows Pro has it but it is optional and disabled by default. Also, Secure Boot uses generic keys which some Linux distributions are also signed with, so if I steal a piece of hardware, there is a 90%+ chance I can just boot Linux and dump the disk contents unencrypted. And if it is encrypted, I could still boot Linux leaving Secure Boot intact, and try glitching the TPM which has been well-documented as quite possible.
Not quite. Windows Home automatically enables disk encryption if you sign in with a Microsoft account (and the device has a TPM 2.0 and Secure Boot). But yes, full BitLocker functionality, such as setting up alternative decryption methods (e.g. requiring a PIN or usb key), is only available on Windows Pro and higher.
Actually there is a caveat. With Windows laptops, rven if you cant read the data, you can wipe them and start fresh. M1 Macs are locked to their owner if left in Lost Mode and are always broadcasting Find My signals when on in that situation.
How is that a caveat? It upholds the ultimate goal of encryption, preventing adversaries from accessing your data. Sounds like you're shifting the goalpost of the word "encryption"...
I assume you mean by not using a Microsoft Account to sign in to the machine. In that case, you literally just right click on the OS drive and click Turn On Bitlocker. It asks you where to save a recovery key and then you’re good to go.
Secure against what? Security isn’t a free floating quantity, it only exists in relation to particular threat models.
Microsoft has, I think rightly, calculated that the risk of losing access their data is worse for most users than the risk that the government gets a warrant for their recovery key.
And if you want to protect against the government, then it’s really easy to set up Bitlocker to not backup to MS. You can change the key with one or two commands, or with a GUI, even if you use a Microsoft account to sign in.
In any case, I’m not saying the Bitlocker design is perfect. There are good arguments to be made in favor of the iOS or Mac models (which are slightly different, even to each other). Microsoft also has the unenviable problem of dealing with shitty OEMs with buggy firmwares that change the PCR values unexpectedly, locking users out of their data and requiring a recovery key.
But your original claim—that physical attack protection is novel to ARM-based Apple devices—is just completely wrong.
Not a crazy thing tbh. Say you and your wife exchange some nudes, maybe make a sex tape (bad idea, but people do it). You put it on your Mac. Many people would rather have everything in their house stolen than let those nudes fall into the wrong hands.
But yes, the more typical scenario envisioned when developing these systems is laptop theft, unattended office PCs (e.g. theft or snooping by contractors), etc.
I had filevault enabled on every mac I owned for this reason - but now it's not clear to me if I still need to do that with the new macs. Does the current defaults prevent someone from ripping out the drive and reading it or do you still need to turn filevault on?
If you use that Mac Studio for work that's a valid attack scenario. In a targeted attack it isn't unheard of that hackers do physical attacks as part of the attack chain.
It's a strange shift and one I've fallen into the trap of. Discord requires kernel extensions for screen sharing and requires the reduced security toggle as a result. I've gladly used screen sharing in the past with presumably the same mechanisms, and not thought twice about it.
Yet for some reason I'm hesitant to reduce the security of my main personal machine, even if that 'reduction' results in a consistent level of security with my old 2015 x64 MacBook. The reality is that I probably need to go and determine if there are a greater volume of more prevalent kernel level exploits to figure out what the factor of risk really is - it may be that these features are exploited more regularly and to greater effect than they were in 2015.
It's an Electron limitation (because of course it is):
> [...] does not work on macOS for audio capture due to a fundamental limitation whereby apps that want to access the system's audio require a signed kernel extension. Chromium, and by extension Electron, does not provide this.
Discord only requires this for sharing audio along with screen sharing - I've shared my screen with the Discord app several times before without audio and I've never installed the kext.
And, at any rate, the kext they want you to install is the same one Rogue Amoeba uses for their well known and widely used app, Audio Hijack. Discord licenses it from them; they mention it in the dialogue that prompts you to install it.
> it may be that these features are exploited more regularly and to greater effect than they were in 2015.
It's not like you allow any kernel extension to run, do you? You still have to approve each of them manually.
Atm I have two usb-serial adapters with different chipsets hanging off the x86 mac mini plus an Arduino that comes with its own usb serial. Is that possible on arm macs?
I don't think that's the reason. It's simply that with an essentially clean room platform, Apple has the opportunity to harden the security. While with the existing Intel platform, people are used to doing certain things that Apple didn't want to break.
Apple still sells models with Intel CPUs. People who buy them presumably don't want their existing workflow to break, and are willing to buy an old generation of CPU to get that.
Just allowing kexts to be loaded should not increase the attack surface or expose the author to any currently known exploits. The reason that people avoid doing it anyways is because third party kexts have a history of obvious vulnerabilities and don't receive the same amount of eyeballs that first party kernel extensions do.
As you put it, it really is a desire for maximum security at play here.
>Just allowing kexts to be loaded should not increase the attack surface or expose the author to any currently known exploits
"Just allowing kexts to be loaded" sure, it wont. But "just allowing kexts to be loaded" makes no sense as an action, unless you also actually intend to and do load at least one kext.
In which case, it absolutely increases the attack surface.
Back up all the documents, files, pictures, videos, and other accumulated stuff on your Mac. You can do this with the built-in Time Machine tool or copy your folders manually. Place the SSD in the case, then connect it to your Mac using the included USB cable. Open "Disk Utility" and format your SSD to A PDF format if available, or to "Mac OS Extended with GUID partition scheme" (on older versions of macOS). For additional data backup, use https://www.salvagedata.com/. I renewed my old 2014 iMac this way, and the effect of the SSD exceeded all expectations.
I've done several migrations from Intel Mac to M1 Mac with zero problems. I did not do it this way. I suspect this is complicating the issue for no reason.
Time machine backup to external disk. Turn on new mac, restore it. Job done. Even the slowest of the migrations, the piecemeal first one was done just shipping data on an SSD.
At no point did I need to boot anything other than the internal disk on either machine.
Yes aware of that but looking at it from an XY perspective it looks like the thing escalated from the approach.
Regarding USB / TB external disks, they do support SMART but only if the controller does forward the info to the Mac. The Mac doesn't give a shit about what's on the other side of the controller. This is where you get some reporting and some not. DriveDx is being used to circumvent that issue by I assume intercepting the commands and forwarding them to the drive. And of course at this point you have to break the secure boot chain by loading kexts that can intercept the disk traffic.
Now worthy of mentioning here, brew installed smartmontools does report SMART status fully on my 970 EVO in the cheapest USB-C enclosure on amazon. It doesn't report it in disk utility but does on the terminal.
YMMV but the problem here may be using the wrong analysis tool or the wrong migration approach.
The disk health and integrity doesn't ensure the data integrity either as it may fail after the health is checked so the validation should be done at a higher level (sha256 the whole migration before and after etc)
I hope we eventually figure out how to replace the internal SSD in the Mac Studio. I was able to replace it in my 2013 iMac and it extended the life another four+ years.
From a previous Twitter thread [0] it seems that Apple could easily provide new modules, and perhaps they’ll keep the same form factor in the future, but I don’t think a third party could. Whilst the flash itself is seemingly standard there is an Apple specific controller too.
Doesn't work on my external hard disks which are connected over USB 3.0. Both diskutil and smartctl report that SMART is not supported. Under Linux, these work just fine.
I mean it's a pretty limited use case, isn't it? The author is basically saying that if:
- you run a production line on a Mac which uses external SSDs;
- you need to check the health of those SSDs regularly;
- those SSDs connect by USB C; and
- you're not prepared to run an install of Mac OS on your internal drive with SIP disabled (which I presume is the security setting they're being required to downgrade),
then you can't fully migrate all of your activities to an Apple Silicon Mac. I don't know how many people that would apply to, but I doubt it would be a huge number, and it's hardly unusual to have either a dedicated machine or separate environment to conduct side tasks that aren't able to be completed in your main environment.
One thing I wasn't clear on was why the author didn't want to format the internal drive to create a separate partition for the SIP-disabled instance of Mac OS. I don't actually see why that would be different (from a security perspective) to running it from an external drive, given that the insecure install wouldn't be running when booted from the secure install (even if they're on the same drive). The author seems to treat it as a binary choice for the main drive in the Mac Studio (ie that it must be 'secure' or 'insecure'), but that's not really how it would work from the perspective of making a second partition's Mac OS install insecure, given that that insecure OS isn't doing anything when you're not booted into it.
If the author was still set on running the install from an external drive, they could partition the internal drive, install Mac OS, disable SIP and install the kext, then clone the partition onto the external drive. If external drives just need to be ejected during the DriveDx install process, this shouldn't stop anyone from running an OS with DriveDx from an external drive after the install. This is obviously a pain, but hardly that much worse from the hoops I've had do jump through on Windows over the years.
I must admit, I'm not familiar enough with SAT SMART or external SSDs that connect by USB C to know why there's no alternative to turning off SIP, or why this was possible on Intel Macs but not Apple Silicon Macs, but it seems like a pretty niche use case from which to extrapolate the conclusion that full migration to Apple Silicon Macs isn't feasible full stop.
Used in article, but only you and GP have mentioned. What is this garbage nomenclature? First of all, what in God's name does "security" mean in this context? It is obviously supposed to stand for somethings specific, this is not just an in general mention of security. What?
And "downgrading?" What is happening here? I am completely and utterly lost on this word and why it is used, here, in this context (the article author's use... and since both you and GP used it, I hoped either could explain to me what is going on with security downgrade like this is a thing, when I expect it really isn't a real thing, someone chose bad words for nonissue, but if not, thx).
It seems like OP issue is that in order to run a third party legacy kernel extension that doesn't follow most recent guidelines he need to disable this safety altogether for the whole OS.
(And there is a separate issue because the third party legacy kernel installer require all external storage to be unmounted at install time, thus preventing installation on an external storage)
I tried to be clear, english is not my mother thong, hope it might help.
*Edit : System Integrity Protection is maybe the more adequate term instead of secure boot
Thank you. So, "security" is System Integrity Protection, a feature of macOS, and "downgrading" merely means disabling it. Sounds like a great big nothing burger.
