91–100 of 117 posts
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.
Earlier quoted context omitted.
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…
marcan seems to be part of a new breed of hacker, less interested in the "why" we do it and more interested in the "how" of it. Works pretty well for tackling a challenge like blindly picking at a black-box ISA/SIP, but I don't think his project has the kind of ideological understanding that keeps the libre desktop alive. Getting it to work is one thing; building a community to maintain your work is another. Unfortun…
I mean, to be honest, someone only knowing “whys” alone is kind of disappointing — especially combined with the often seen narcissism of developers and you get someone who does not understand the problem domain spewing bullshit about it with confidence. We can see plenty of examples to that under any firefox, wayland or systemd threads.
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…
But it's a lot more than just "go ahead".
For stock users: enabling dev mode wipes storage and reinstalls CrOS, so trying to "attack" via dev mode a) won't give the attacker any data and b) will be extremely noticeable because the data is gone (and there will also be dev warning screens all the time unless they then make fully custom FW and CrOS that aren't secure but look exactly like stock)
For custom users: you can lock the debug interface with your password! Plus do your own vboot if you're concerned about.. ehh.. flashing over SPI directly bypassing the debugger (not easy on some devices) or somehow some vulnerability allowing internal flashing from the CPU.
So Chromebooks do have decent measures against physical access and allow for full CPU & EC firmware customization.
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…
> On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. Even then, it isn't always obvious how to write that image to flash. Sometimes you get lucky and the downloadable BIOS is a full image of the serial flash chip, but sometimes it's a delta update, or the flash chip contains other data (like configuration) which isn't part of the public image. And even then,…
Also, high end "gamer" hardware often includes "dual BIOS" (on both mainboards and graphics cards) and/or "BIOS flashback" (special button makes a microcontroller flash an image from a USB stick inserted into a marked port, even without a CPU present).
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…
The screw hasn't been a thing for years, you prove ownership by sitting there for like 15 minutes pressing the power button when told :D But it's a lot more than just "go ahead". For stock users: enabling dev mode wipes storage and reinstalls CrOS, so trying to "attack" via dev mode a) won't give the attacker any data and b) will be extremely noticeable because the data is gone (and there will also be dev warning scr…
Can you recover a modern Chromebook that has had all of its Flash memories tampered with or wiped externally, with just a USB cable? With a debug cable? That seems to be one of the major things that sets apart iDevices from others.
At least this design doc still says local attacks involving e.g. replacing writable storage are out of scope (which they very much aren't for iDevices):
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
From block diagrams it seems Cr50 security chip in recent Chromebooks just interfaces with AP Flash and the write protect pin, and thus verified boot isn't tied to silicon tamper resistance. That puts Chromebook at around the same level as T2 Macs in terms of tamper-resistance, in fact a bit worse (on T2s the T2 chip is the flash from the AP's point of view, so you can't just tamper with an external flash memory. You could MITM it in principle, though I heard the T2 Mac boards are also designed to make this difficult to pull off with buried traces).
Digging a bit more (the docs on this are really scattered...), it seems Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable, but that requires taking apart the machine, since it won't work over USB, only UART. There is no mention of any Boot ROM recovery mechanism or of how the RO firmware is authenticated; RO is supposed to be "Read Only" in on-chip Flash, but eliminating every avenue for compromise of writable Flash is very hard (e.g. glitching the Boot ROM; I've seen too many "secure" microcontrollers compromised to bypass read or write protect in various ways...), so this approach is quite a bit weaker than Apple's: on these devices, you need specialized hardware to go to the lowest level of recovery, and you can't even recover from certain kinds of volatile storage loss or compromise, while on Apple devices any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware on the machine to factory condition, and the process relies only on truly immutable mask ROM*.
* I can't say for sure there isn't any auxiliary writable flash that would let you brick the machine in some other way, but I haven't found anything yet. The prime suspect, the USB-PD controller chip that's in the path of the DFU USB connection (and thus could break it if it doesn't work), smells like it boots from ROM until the OS instructs it to launch the application image from Flash. It reports being in "DFU" mode until we issue the first power state switch command to bring it up, and we know these chips are custom Apple versions with Apple ROMs and the ROM does contain most of the USB-PD stack... so this sounds like the kind of thing Apple would get TI to do, since they really care about being resistant to bricks and persistent compromise.
Earlier quoted context omitted.
> comes almost 20 seconds after the start. Wait... an M1 Mac takes 20 seconds to boot?? A middle of the range windows machine in 1996 booted quicker than that...
It does not, not fresh and without boot time actions to take. Certainly not the laptops. The Mac Mini used to have a larger delay dependent on the monitor attached, due to monitor detection times; about 7 seconds to the XNU kernel being launched, or 13 without a monitor (I guess it waits for monitor detection to time out), but now that Apple removed boot-time display support on those I imagine it no longer matters. T…
For comparison, a ThinkPad X230 running Arch takes 7 seconds to GRUB (which I skipped through as fast as possible), FDE unlock prompt at the 12 sec mark, and after typing in my password it takes a further 13 seconds to get to a graphical login prompt (so 25 seconds total time).
Honestly, adjusting for the fact that Linux does fewer things before the FDE unlock than macOS, and more things after it and before the login prompt (I've got a few extra daemons and thing installed), I'd say they're quite comparable. The MacBook is a bit better (2s faster firmware without the chime).
Of course, half the point of these machines is they can run weeks while in sleep mode (or even while powered on as long as the CPU is idle and the display is off) and they have practically instant wake. So boot time isn't really relevant, since you rarely have to shut down.
Earlier quoted context omitted.
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...
I think if Apple was to add a developer mode to the iPhone, 99% of people would actually shut up.
Earlier quoted context omitted.
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...
To be fair to the other side of the argument, I think people are mostly upset about the iPhone. There's an implicit fear (which I don't agree with!) that if Apple is so insistent on keeping the iPhone locked down, that must be their ultimate goal for their other platforms as well. I think if Apple was to add a developer mode to the iPhone, 99% of people would actually shut up.
Earlier quoted context omitted.
To be fair to the other side of the argument, I think people are mostly upset about the iPhone. There's an implicit fear (which I don't agree with!) that if Apple is so insistent on keeping the iPhone locked down, that must be their ultimate goal for their other platforms as well. I think if Apple was to add a developer mode to the iPhone, 99% of people would actually shut up.
People seem to forget that the iPhone is 15 years old, and Macs are still an open platform. It hasn't happened yet, but somehow it's always "going to happen"...
I just don't think that the counterargument is completely spurious. Craig Federighi taking the stand in court and saying that Mac security is at a place they "don’t find acceptable" doesn't exactly make me feel all warm and fuzzy about Apple's future plans. And so if someone says they don't want to buy an M1 Mac, even if it's open today, because they see the iPhone as indicative of the direction Apple is going, I think that's fair, even if I disagree about Apple's intentions.
By contrast, if Apple added a way to unlock the bootloader on iPhones tomorrow, this argument would immediately evaporate. :)