Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Secure Boot Works on M1 Series Macs

eclecticlight.co

Post reply on HN
Print view View original

81–90 of 117 posts

Re: How Secure Boot Works on M1 Series Macs

#81

Post by marcan_42 »

cmurf wrote: post #57
lovelyviking wrote: post #26

Earlier quoted context omitted.

>If you completely don't trust Apple, then you absolutely should not use their hardware at all. So some level "trust Apple" is simply a security axiom on this platform. It is not about trusting Apple or any other company for that matter. It is about tendency and attempt to make it a norm/legalize to sell personal computers without respecting right of the owner to have a full control over their own computer. If owner…

I agree it's "your own device", but Apple's EULA makes it really clear it's only your own device insofar as you can choose to destroy it. They retain a residual right over the hardware, a partial ownership if you will, when it comes to what software is on it. You aren't buying hardware. You're buying an experience. You don't have the right to experience arbitrary software running on it, even if you trust it. It's one…

Apple's EULA explicitly allows you to replace the open source components of the OS with your own. One such open source component is the XNU kernel itself. This is what allows Asahi Linux to exist not just technically, but also in full compliance with Apple's EULA.

Re: How Secure Boot Works on M1 Series Macs

#82

Post by marcan_42 »

lovelyviking wrote: post #32
jeff_vader wrote: post #24

Earlier quoted context omitted.

It really depends on the threat you are planing against. If for some reason I'm target of US government - I'm screwed anyway. If my concern is trusting the laptop after I left it in train station and got it back from some random dude - it's good enough.

How about much simpler scenario, no threat at all. Just dumb bug in software that puts your computer in DFU mode that says, please connect it to another Mac. Nice isn't it? And then you should run and find 'another mac'. What if there are no other macs around? What if you travel and have no connection to the internet or it's limited ? This is not a hypothetical situation, this is exactly what have happened in my case…

> What if there are no other macs around?

https://github.com/libimobiledevice/idevicerestore

Re: How Secure Boot Works on M1 Series Macs

#83

Post by marcan_42 »

est31 wrote: post #80
marcan_42 wrote: post #70

Earlier quoted context omitted.

For comparison, note that you can't do low level recovery at all on e.g. Google Pixel phones. Lose the contents of your storage there and the phone is bricked, as Google does not provide the low level flashing tools and signed images to do that. Apple does, with the phone home caveat. On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. So it's better in that y…

Google Pixel phones are phones though, and not personal computer devices like M1 Macs are. Phones have traditionally been more locked down. A fairer comparison would be to Chromebooks, which do have a screw to let you flash a different BIOS.

Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model.

We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it. Apple's security model aims for this, while still allowing the user to install their own OS.

Re: How Secure Boot Works on M1 Series Macs

#84

Post by marcan_42 »

smoldesu wrote: post #55
hraedon wrote: post #43

Earlier quoted context omitted.

All sentiments like this one and those similar to it elide the facts that 1) we’ve tried relying on “user responsibility” before, and excusing the comically bad outcomes through victim blaming doesn’t change them; and 2) we didn’t get together and vote Apple the only manufacturer of computers. If you don’t like their model, choose someone else. Why should average users who would otherwise be served perfectly well by…

User responsibility and device safety are not mutually exclusive. You can keep the iPhone exactly as-is and add a developer mode that would pretty much shut up every nerd this side of the Mississippi.

Which is exactly what they did with M1 (add a developer mode that doesn't put their normal users at risk by allowing for persistent supply chain compromise attacks), but it doesn't seem to be enough to make some people happy...

Re: How Secure Boot Works on M1 Series Macs

#85

Post by marcan_42 »

microtonal wrote: post #17
rubicks wrote: post #11

Could anyone explain how the firmware (implementing UEFI, I assume) interacts with the components described here? My knowledge is limited to Tianocore edk2 on amd64 platforms.

There is no UEFI, only a simple boot ROM and the first stage of iBoot is in NOR flash. The rest is all on NVMe. There is a detailed description here: https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot

I should update that, there are a few minor inaccuracies, but it's mostly still correct given our present knowledge :)

Re: How Secure Boot Works on M1 Series Macs

#86

Post by marcan_42 »

mlyle wrote: post #60
lovelyviking wrote: post #59

Earlier quoted context omitted.

>If your fundamental firmware-stuff is screwed up on any platform Sure I just have an impression after some googling that this DFU happens much more frequently then one would expect. Certainly I didn't expect it to happen in the first day after purchase but it did. So perhaps this pleasing 'much better' ability to fix it by just connecting it with another device that you probably do not possess(in my case) comes with…

I have never had to deal with firmware on Apple hardware (excepting "zapping the PRAM" on classic Macs). I've had to deal with it dozens of times on other platforms. We have 3 Apple Silicon based Macs in the house, and there's 4-5 others that I support. So far 0 incidents in about 3 device years. I don't think it's tremendously common like you imply. In the same time period, I built two Ryzen machines, and had to swa…

I've bought one of every major M1 model for testing purposes and have done all kinds of crazy things to them, and the only time something weird happened was with the original firmware version where I managed to break recovery mode by messing with diskutil, but I was able to fix it from macOS without requiring a DFU flash. It's never happened again and I've done the same thing dozens of times, so I think that was some silly bug in the shipping firmware version that has long since been fixed. I never actually had to resort to DFU recovery (though I still tested it a bunch as part of improving support for it in idevicerestore).

Re: How Secure Boot Works on M1 Series Macs

#87

Post by marcan_42 »

lovelyviking wrote: post #41
argsnd wrote: post #38

Earlier quoted context omitted.

Just use https://github.com/libimobiledevice/idevicerestore on a Linux or Windows machine. Yes, if you don't have internet access you have a problem, but I'm personally happy enough with the benefits of this security model that I'm willing to accept the tradeoff.

>I'm happy willing to accept the tradeoff. For now ... Thank you for the link but may I suggest you to think about the future and where it leads.

The Mac has existed for 37 years and the iPhone for 15 of those and the Mac is still open to running whatever OS users choose. You really need to find an argument other than an unqualified "the future is doom and gloom" when after all this time that future hasn't come and the platform remains open.

Re: How Secure Boot Works on M1 Series Macs

#88

Post by AnthonyMouse »

marcan_42 wrote: post #83
est31 wrote: post #80

Earlier quoted context omitted.

Google Pixel phones are phones though, and not personal computer devices like M1 Macs are. Phones have traditionally been more locked down. A fairer comparison would be to Chromebooks, which do have a screw to let you flash a different BIOS.

Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model. We in security l…

> We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones.

People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist.

Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomorrow are there right now, if you have the resources to look.

And this is distinct from the level of resources (generally considered impractical for anyone) for other forms of computer security, e.g. AES replaced 3DES in 2001 but still to my knowledge nobody -- not even the NSA or other state actors -- has ever even broken 3DES.

If you ask whether a large corporation could break into an iPhone today given physical access, the answer is going to be yes. And without decapsulating your CPU. The physical vulnerabilities often end up being related to USB and things like that.

Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it.

> You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it

Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it.

And that's really the physical access problem. If you have a device with full disk encryption and have cleared the keys from memory, the attacker might not be able to get the contents even with physical access. But if they've had physical access and then return the device to you, can you still trust it? Nope.

Re: How Secure Boot Works on M1 Series Macs

#89

Post by marcan_42 »

AnthonyMouse wrote: post #88
marcan_42 wrote: post #83

Earlier quoted context omitted.

Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model. We in security l…

> We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomor…

> People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist.

Most of which are tethered, which means they do not persist through reboots. And even if they're untethered, you can recover the platform with a DFU restore.

Those jailbreaks only exist due to flaws in Apple's software, which is completely outside the premise that physical access means game over. If Apple's software were bug free there would be no practical jailbreaks, and physical access has nothing to do with it. Some of those jailbreaks work through remote access, like the ones used by NSO and company.

And again, this is why they have the signing feature when installing an OS - so you can't install an older version vulnerable to a jailbreak and then give the phone to someone.

> The physical vulnerabilities often end up being related to USB and things like that.

Those aren't physical, they're software - checkm8 was a bug in the boot ROM. And this is why iBoot on M1 Macs doesn't support USB host mode to boot from USB disks, because the attack surface there is massive and Apple decided to find another way to allow macOS boots from USB without exposing their more critical bootloader to that.

Nobody jailbreaks iPhones via physical vulnerabilities, but if they tried, Apple have been much more proactive in this area than pretty much everyone else too. They have things like memory encryption and authentication for the SEP memory area, environmental monitors, hardware design that avoids exposing things to software that could have a security impact, etc.

> Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it.

And every new iPhone and every bug fixed, this gets harder. The attack they used for that phone no longer applies to newer ones. It's not just a game of whack-a-mole either; Apple have been at the forefront of attack mitigations and iDevices are some of the most secure consumer devices in existence (the Xbox One might be close).

Doesn't mean they get it perfect; I have an Apple security report open for a bypass for one of their mitigations. But they try harder than pretty much everyone else in the industry.

> Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it.

That might work to get your PIN, but if nothing else you'd immediately notice it doesn't work properly or all your data is gone. That sure beats a silent backdoor in your phone.

Re: How Secure Boot Works on M1 Series Macs

#90

Post by marcan_42 »

lovelyviking wrote: post #36
GeekyBear wrote: post #31

Earlier quoted context omitted.

> It is about tendency and attempt to make it a norm/legalize to sell personal computers without respecting right of the owner to have a full control over their own computer. If owner cannot fully control own computer this computer cannot be called 'personal' anymore. I have bad news about Intel CPUs. >[Intel] processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what vers…

therefore I've said this before: The full control of devices you own is absolutely essential. It requires a complete transparency of basic components like cpu micro-code, firmware and hardware otherwise it can and will be abused. [0] .. unless everything is absolutely transparent including microcode and hardware it is not acceptable as freedom respecting solution. [1] then I've got unexpected opposition from the one…

I love how every time you bring this up you link every post except the one where you compared Apple to a dictatorship, then went on to insult every user who chooses their hardware over others.

I'm happy to debate the pros and cons to different security approaches, and I want every prospective buyer of these machines to be informed about the decisions and trade-offs that went into their deaign, and what to expect. I'm not interested in debating someone who immediately dismisses all technical discussion and just invokes references to authoritarianism, brings up boiling frogs with no evidence, immediately dismisses my arguments as wrong and assumes they need correction, and ends with ad hominem attacks.

As I said, go buy a Pinebook and please leave the rest of us alone. We're trying to give the users of these machines choice. You're trying to take away our choice to use them through moral arguments.

Post reply on HN