I Love Arch, but GNU Guix Is My New Distro

See, the funny thing is that Apple's M1 devices are less backdoorable than the FSF's "Respects your Freedom" laptops. That's because unlike those obsolete laptops, Apple's designs actually firewall off all the blobs and coprocessors using IOMMUs, and those IOMMU configurations are introspectable by system software so it can confirm they are correct and not granting too much access. That means if you boot Linux on an M1, and you check the IOMMU configs (most of which are not locked, but those which are are readable), you can say "yup, this isn't backdoored". There is also no nested virtualization support on those machines, and the design of ARM virtualization makes it impossible to "hide" a secret backdoor hypervisor. There is also no ME or any other hyper-privileged software. On top of that, the fact that Apple uses code signing for their entire boot stack means that only they can theoretically (though as I said, in practice detectably) backdoor your laptop - that's much better than the RYF laptops, which have no security and therefore anyone in the supply chain can backdoor them. Oh yeah, and all the post-boot blobs on M1s are stored in the filesystem or readable Flash memories, so you can actually audit them, unlike all those microcontrollers with LPC access to all system RAM on the RYF machines. That's just nasty, the perfect design for an invisible backdoor.

So yes, the FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations, while Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device. And you can put Linux on those Macs and run a fully open source kernel and userspace - not very different from those laptops in the end. Think about that.

Of course, I am very happy to talk at length about the design of these machines with everyone, and I want all the users of my software to be aware of these things (yes, there are a ton of blobs here - the amount of damage they can do is less than the blobs in the RYF laptops, but they still exist), as well as the things we don't know (e.g. some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable, but we'd like to find out and if it is, that would be a firmware bug to report to Apple). I believe that in order to make an informed decision, users need to have all the information.

>FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations

but they are promoting such devices on ethical concerns, not on security concerns. they are not deceiving anyone

>Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device

you mentioned FSF fanboys before. there are way more Apple fanboys who are convinced that their Apple products respect their privacy and that their devices are impenetrable. what is worse, Apple markets itself based on this grotesque misperception!

if security and privacy is a vital concern for people, Apple devices are NOT products that should handle their security concerns! you promoting Apple as secure makes you guilty of the very thing you accuse FSF of actually

i would absolutely love it if there is a public non-profit organisation like FSF that is security/privacy focused - eg Secure Software Foundation - that would employ security experts to analyse and audit security and privacy of all software, free and non-free, and of course always open their findings immediately. moreover, i would definitely hope that such an organisation would be as autistic and unwavering toward open security and privacy as FSF is toward software freedom :)

the fact of the matter is, while you can support both free and secure software seperately, they are seperate matters. it is possible to come to a conflict of interest type scenario. secure-software and free-software, although often sharing the same concerns, are simply not the same thing

I think Apple are a corporation with interests that happen to result in them building secure, high performance, quite trustable hardware. Since they have the motive to do so, and since everything I've seen suggests they indeed are, and since their hardware officially allows me to run my own software on it, I would much rather use their hardware (with my own OS/software) than whatever the FSF labels as RYF, which is a label that, in my view, says nothing I care about, not even about my freedom.

Whether Apple is ethical or not is a different question. There is plenty of criticism to be fired at them for various issues. That's a personal call for people to make. I'm not saying you should go buy Apple hardware. I'm saying it's significantly more trustworthy from a security and privacy standpoint than x86 machines. Do they respect my software freedom? About as much as the RYF machines. They both let me run my own OS and they both rely on proprietary firmware for various things. The FSF's certification criteria do nothing for my software freedom (which has nothing to do with whether blobs are in ROM or RAM), they just hurt security, which is something else I care about.

We all have to make our own decisions about what to purchase based on the information available to us. That is why having such information is so important. If you value repairability more than anything, you should probably get a Framework. If you value security above all, you should get a Precursor device. If you want a trustable machine that's still high performance, you should get a Mac. If you want to run Windows games, you should get a gaming PC. If you value your freedom... there isn't anything truly free out there. RYF machines certainly aren't it, nor more free than many others by practical measures, nor transparent about their design.

Hence why I criticize the program. It's not achieving anything positive. It's just a feel good thing; the FSF says it respects my freedom so I can feel good about being Free™ while running more proprietary firmware than many other off the shelf machines.

Just to put things into perspective, I believe Google have done more for computing device freedom than the FSF, because the Chromebook team is notoriously pretty much the only large team which actually pushes for open source everything pretty hard, and they're important enough that some vendors listen, and they have the money to develop things themselves. For example, if you look for an open boot/OS stack for the Tegra X1, the closest you're going to get is the Chromebook Pixel's. Only the RAM training blob is closed source (and there is a reverse engineered replacement these days). Everything from the low level bootloader to the GPU drivers are open. This is no thanks to Nvidia - for pretty much all other customers they offer proprietary bootloaders. Also, I'm pretty sure some Chromebooks even have open source EC firmware, which those ThinkPads the FSF loves so much don't.

> only they can theoretically (though as I said, in practice detectably) backdoor your laptop

No, no no. This is wrong. You don't need a nested hypervisor to make an undetectable backdoor. If you you audit all network traffic from a separate device, most backdoors are detectable, because a backdoor wants to have some effect that goes outside your system and that is the obvious route. But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

So the M1 firmware is meant to be updated, right? Proprietary updates are the means by which a company exercises unacceptable control. The next update to the network card firmware could check the signature of the OS and stop working.

> some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable

Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open? Seems more likely that this whole theory of yours has a whole in it, that some firmware does have access to change important data.

Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties. Well, you may argue that that is more important than software freedom. Ok, but, then that vendor can then make whatever terms and conditions it wants on those updates, and that includes breaking your security. So, one day, the vendor says: run our proprietary updating software, is every user going to reject it because they realize the security implications? No. And the vendor says: our firmware updates are only distributable through MacOS, so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux. Sounds like a good way to kill GNU/Linux for 99% of users who don't got time for that. Wait, isn't that the situation for M1 laptop users? Riiight.

> No, no no. This is wrong

Look, I'm not a fan of pulling on credentials, but I've literally spent the past year reverse engineering these devices. If you're going to tell me I'm wrong about my security analysis, I hope you've done your own.

> But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.

> The next update to the network card firmware could check the signature of the OS and stop working.

The network card is behind an IOMMU and sees exactly what the OS wants it to see. It has no way to check the signature of the OS.

This whole argument is moot anyway, because of course Apple could release a new OS/firmware version that removes the bootloader unlock tools. I've had this discussion a million times already. Apple spent a significant amount of time developing these tools and the infrastructure to allow these unlocks, and I do not believe they would ever do this, as it would be a massive 180 and incur a huge PR hit, nevermind expose them to legal action. If you believe otherwise, then don't buy these machines, or just never update the firmware once you get one. Also don't buy any Android phones, any x86 PCs with Boot Guard, etc., as they all suffer from the same hypothetical retroactive lockdown threat.

> Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open?

We are still reverse engineering these machines. It's not just the IOMMUs. There are other layers of address filtering. We don't know what those streams do, therefore we can't say whether they're evil or not. Given how carefully Apple has designed these things to prevent this, I have no doubt that if there's a path for one of these coprocessors to access all RAM, that's a bug, and if I can confirm that, that'll be an email to product-security@apple.com with a 90 day disclosure deadline, and they'll fix it. It wouldn't be my first rodeo with Apple product security either. They're good, but they're human. They make mistakes.

But we can't say that right now because we literally don't know what's plugged into that port on the IOMMU. It could be a hardware block with an address filter or otherwise controlled by the main CPU anyway. Or it could be outright unused and a vestige of something they were doing on iOS. I can certainly tell you that the main IOMMU port used by the coprocessor subsystem in question does not have access to all RAM. They've been very careful to design the whole SoC like that. If there's a hole, it's a bug.

> Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties.

You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom. In fact, most devices with the kind of little ROMs the FSF loves to ignore, like keyboards, would not use signed firmware if they had a RAM design instead. That means you absolutely gain freedom with the RAM version - the freedom to reverse engineer the proprietary firmware and write your own, or install an open version someone else has already made.

> Wait, isn't that the situation for M1 laptop users? Riiight.

I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet. You can, however, already use DFU mode with another Linux machine running idevicerestore to apply these updates without wiping the whole system nor requiring a macOS install, if you really want to (though it's not the best method because it wipes some stuff that makes it not completely seamless, but it doesn't wipe your OS).

> so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux.

Or you could just dual boot, which is how I expect 95% of our users to use the system. We recommend keeping a macOS install around at this point for various practical reasons. The machines natively support multi-boot and we take full advantage of that. Please learn more about the system architecture before making up FUD.