5 ms·

There's also the Raptor Computing Talos line ... which is interesting, all open firmware and busses, but even more expensive and less practical unfortunately. h

There's also the Raptor Computing Talos line ... which is interesting, all open firmware and busses, but even more expensive and less practical unfortunately. https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/

marcan_42 5y ago
Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) In the end, you're always drawing arbitrary lines in the sand. If you really want to go all the way to actually reach a tangible goal, I'm only aware of one project that actually offers trust guarantees backed by hard engineering arguments: Precursor https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor (TL;DR on the trick is that, by using an FPGA, you make it nearly impossible to backdoor, because it would take a huge amount of compute power to engineer a backdoor into the FPGA silicon that can analyze arbitrary randomized FPGA designs to backdoor them). For more practical computing, I find M1s have a very solid secureboot design. We can retain that security even after putting m1n1/Asahi on there; doing so requires physical presence assertion and admin credentials and locks you into a single m1n1 version without repeating the process, so we can use that to root our own chain of trust. Similarly we can continue to use Apple's SEP (in the same way one would use a TPM, HSM, or a YubiKey for that matter; sure, it's a proprietary black box, but it also can't hurt you except where you let it) just like macOS does, for things like encryption and storing SSH secrets. And all the coprocessors have IOMMUs, and the whole thing is very logically put together (unlike the giant mess that are Intel CPUs; e.g. we know they have a JTAG backdoor in production chips after authenticating with keys only they have, never mind things like ME) and designed such that the main OS does not have to trust all the auxiliary firmwares. I'd love to have a more open system competing in the same space, but I have no problem trusting Apple's machines much more than I do the x86 PCs I use these days anyway, and it's hard to find things that compete in the same performance/power space that are more open than either of those, unfortunately.
- marcodiego 5y ago
  > Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) Safety is not binary.
  - marcan_42 5y ago
    Having to trust a particular entity is binary. I have to trust Apple not to give the government a physical-access backdoor to my machine, just like you'd have to trust your silicon vendor not to do the same (e.g. the Intel JTAG password stuff I mentioned). If you have an open system that does not do robust secureboot (i.e. secureboot that can withstand a physical access attack), then it doesn't matter that it's open; a physical attacker can still break into your machine and backdoor it. If it does do robust secureboot, it is pretty much guaranteed to rely on a proprietary ROM, which will likely have backdoors or exploitable bugs (see e.g. Nvidia Tegra machines; yes you can burn in your own secureboot keys on systems that come unlocked like the Jetsons, but their ROM is a mess and all their security is now moot as you can exploit it). Apple have a lot of experience with this, having long been one of the prime targets, and have put a lot of effort into hardening their boot chain, so I trust them to do a better job than pretty much any other silicon/firmware vendor (and I say this as someone who has looked at the security of many vendors). People like conflate openness with trustability, but they do not go together. Most open systems I see being developed explicitly choose not to enable or support this kind of security, which makes them less trustable systems than an Apple machine: I don't care that all the boot process is open and I can inspect it, if anyone else who steals my laptop or messes with it while I'm away can steal my data. You need to rely on maintaining physical control. With an Apple machine, you don't: only Apple can break its security, nobody else, so your data is safer as a result. The machine is designed so I do not have to trust Apple's components to be reasonably confident that my machine is safe once it boots into my own OS, thanks to the IOMMUs and general design of the ARM architecture (e.g. a transparent malicious hypervisor isn't really possible). And none of this has anything to do with remote access backdoors (there is nothing like ME on these machines), so the entire story is about what you can do with physical access. That is not to say there wouldn't be advantages to fully open systems; for example, it would allow for a simpler and more user-friendly installation process than what we have to do with Apple's framework, and it would make the DCP thing much less of a mess. There are definitely practical, real advantages to having a more open system. It's just that all too often I see the trust/security argument being thrown around and... that just isn't true in most cases, when you look at the details.

marcan_42 5y ago

Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) In the end, you're always drawing arbitrary lines in the sand. If you really want to go all the way to actually reach a tangible goal, I'm only aware of one project that actually offers trust guarantees backed by hard engineering arguments: Precursor https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor (TL;DR on the trick is that, by using an FPGA, you make it nearly impossible to backdoor, because it would take a huge amount of compute power to engineer a backdoor into the FPGA silicon that can analyze arbitrary randomized FPGA designs to backdoor them). For more practical computing, I find M1s have a very solid secureboot design. We can retain that security even after putting m1n1/Asahi on there; doing so requires physical presence assertion and admin credentials and locks you into a single m1n1 version without repeating the process, so we can use that to root our own chain of trust. Similarly we can continue to use Apple's SEP (in the same way one would use a TPM, HSM, or a YubiKey for that matter; sure, it's a proprietary black box, but it also can't hurt you except where you let it) just like macOS does, for things like encryption and storing SSH secrets. And all the coprocessors have IOMMUs, and the whole thing is very logically put together (unlike the giant mess that are Intel CPUs; e.g. we know they have a JTAG backdoor in production chips after authenticating with keys only they have, never mind things like ME) and designed such that the main OS does not have to trust all the auxiliary firmwares. I'd love to have a more open system competing in the same space, but I have no problem trusting Apple's machines much more than I do the x86 PCs I use these days anyway, and it's hard to find things that compete in the same performance/power space that are more open than either of those, unfortunately.

marcodiego 5y ago
> Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) Safety is not binary.
- marcan_42 5y ago
  Having to trust a particular entity is binary. I have to trust Apple not to give the government a physical-access backdoor to my machine, just like you'd have to trust your silicon vendor not to do the same (e.g. the Intel JTAG password stuff I mentioned). If you have an open system that does not do robust secureboot (i.e. secureboot that can withstand a physical access attack), then it doesn't matter that it's open; a physical attacker can still break into your machine and backdoor it. If it does do robust secureboot, it is pretty much guaranteed to rely on a proprietary ROM, which will likely have backdoors or exploitable bugs (see e.g. Nvidia Tegra machines; yes you can burn in your own secureboot keys on systems that come unlocked like the Jetsons, but their ROM is a mess and all their security is now moot as you can exploit it). Apple have a lot of experience with this, having long been one of the prime targets, and have put a lot of effort into hardening their boot chain, so I trust them to do a better job than pretty much any other silicon/firmware vendor (and I say this as someone who has looked at the security of many vendors). People like conflate openness with trustability, but they do not go together. Most open systems I see being developed explicitly choose not to enable or support this kind of security, which makes them less trustable systems than an Apple machine: I don't care that all the boot process is open and I can inspect it, if anyone else who steals my laptop or messes with it while I'm away can steal my data. You need to rely on maintaining physical control. With an Apple machine, you don't: only Apple can break its security, nobody else, so your data is safer as a result. The machine is designed so I do not have to trust Apple's components to be reasonably confident that my machine is safe once it boots into my own OS, thanks to the IOMMUs and general design of the ARM architecture (e.g. a transparent malicious hypervisor isn't really possible). And none of this has anything to do with remote access backdoors (there is nothing like ME on these machines), so the entire story is about what you can do with physical access. That is not to say there wouldn't be advantages to fully open systems; for example, it would allow for a simpler and more user-friendly installation process than what we have to do with Apple's framework, and it would make the DCP thing much less of a mess. There are definitely practical, real advantages to having a more open system. It's just that all too often I see the trust/security argument being thrown around and... that just isn't true in most cases, when you look at the details.