Earth is limited. Resources are limited. You can't recycle to infinity. Each time you recycle something, the material recovered is worse than before. Steel is weaker, plastic has impurities and is not clear/transparent, paper isn't white and it contaminates the printers with dust, etc. To keep maintaining quality, fresh material must always be added to the recycled one. Everything we dig out of the Earth is non-renewable. (not in the next million years or so...)
The logical conclusion is that at some point we run out of resources. No more oil, no more uranium, no more iron, no more copper, no more lithium. If we don't degrow voluntarily, then we degrow involuntarily and that's usually sudden and it's called a crash. With no resources, what comes next is dark ages, very dark and loooong dark ages this time. Without steel it we'll go back stone age most probably. I won't live to see it, our children won't live to see it, but unless we all nuke each other over some oil fields or something, someone will live to see it.
Degrowth will extend our present good times. Growth will shorten it.
The lifespan of the earth is not infinite, pretending it is is foolish. We have about 5 billion years on earth before it will be consumed by the sun. Presuming an infinite earth creates a very obvious, simple, and wrong conclusion about something that is actually very difficult problem.
>The logical conclusion is that at some point we run out of resources.
The point of renewable resources -- like solar -- is exactly that they are renewable or effectively infinite.
Continue your argument. Don't stop at solar. In the next 5 billion years we must leave. How do you propose we do that if we focus on fast fashion and changing cars every 2 years?
I’m skeptical how much those things are contributing to the end of society. My main concern is GHGs, after that, these behaviors are wasteful, yes, but the vast majority of the limited resources can be recaptured.
You’re not really addressing the obvious though: that at the rate that we are consuming and polluting the earth, we could be pushing ourselves into extinction faster than the sun could just naturally swallow up the earth. I don’t think anyone is debating this eventual death of our star, but our astronomers would very much like to live long enough for us to find another home planet and develop the technology to get there.
I mean, I’m advocating for renewable resources… that doesn’t me arbitrarily stopping consumption. It means reorienting consumption to being responsible.
Mechanized farming, for example, prevents famine because it’s wildly more efficient than subsistence farming. Arbitrary “degrowth” does not address the fact that consumption isn’t arbitrary.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it?
Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
> Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it?
Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2.
Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0. You're kinda pointing out a real problem, but confusing it with a different part of the stack.
> there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0
It's not the same!
A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.
I mean, it's not uniformly literally technically identical, but yes, an Android phone running its OS in ring 0 while other OSs run in other VMs on top of the EL2 (ring -1) hypervisor under the supervision of the Secure Monitor in L3 (ring -2) is very much in the same boat.
What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.
I've a bunch of devices running coreboot with a Tianocore payload, but they're largely either very weird and now unavailable or I haven't upstreamed them so it's not super helpful, but it's absolutely not impossible and you can certainly buy Librebooted devices
Let's say some hw manufacturer would open-source the required specs to implement it on it's chips. (Very unlikely, but let's say they do...) So what? Dangerous capabilites remain.
Until UEFI and secure boot, SMM would run code provided by the BIOS. BIOS was updatable, moddable, replaceable. See coreboot and numerous BIOS mods such as wifi whitelist removal.
Trustzone usually runs code from eMMC. These chips are programed in factory with a secret key in the RPMB partiton. It's a one-time operation - the user can't replace it. Without that key you can't update the code Trustzone executes. Only the manufacturer can update it.
Also, any ring -2 code can be used for secure boot locking the device to manufacturer approved OS, enforce DRM, lock hardware upgrades and repairs, spy, call home, install trojans by remote commands, you name it. And you can't audit what it does.
To respond in more detail: secure boot (as in the UEFI specification) does nothing to prevent a user from modifying their system firmware. Intel's Boot Guard and AMD's Platform Secure Boot do, to varying degrees of effectiveness, but they're not part of the UEFI spec and are not UEFI specific. I have replaced UEFI firmware on several systems with Coreboot (including having ported Coreboot to that hardware myself), I am extremely familiar with what's possible here.
> Trustzone usually runs code from eMMC.
This might be true in so far as the largest number of systems using Trustzone may be using eMMC, but there's nothing magical about eMMC here (my phone, which absolutely uses Trustzone, has no eMMC). But when you then go on to say:
> Without that key you can't update the code Trustzone executes. Only the manufacturer can update it.
you're describing the same sort of limitation that you decried with SMM. As commonly deployed, Trustzone is strictly worse for user freedom than SMM is. This isn't an advantage for Arm.
> Also, any ring -2 code can be used for secure boot locking the device to manufacturer approved OS
No, the secure boot code that implements cryptographic validation of the OS is typically running in an entirely normal CPU mode.
> enforce DRM
This is more typical, but only on Arm - on x86 it's typically running on the GPU in a more convoluted way.
> lock hardware upgrades and repairs
Typically no, because there's no need at all to do any sort of hardware binding at that level - you can implement it more easily in normal code, why make it harder?
> spy
When you're saying "can be used", what do you mean here? Code running in any execution environment is able to spy.
> call home
Code in SMM or Trustzone? That isn't literally impossible but it would be far from trivial, and I don't think we've seen examples of it that don't also involve OS-level components.
> install trojans by remote commands
Again, without OS support, I'm calling absolute bullshit on this. You're going to have an SMM trap on every network packet to check whether it's a remote command? You're going to understand a journaling filesystem and modify it in a way that remains consistent with whatever's in cache? This would be an absolute nightmare to implement in a reliable way.
> And you can't audit what it does.
Trustzone blobs do have a nasty habit of being encrypted, but SMM is just… sitting there. You can pull it out of your firmware. It's plain x86, an extremely well understood architecture with amazing reverse engineering tools. You can absolutely audit it, and in many ways it's easier to notice backdoors in binary than it is in source.
Trustzone is mostly deployed on Devicetree-based platform. What saves you here isn't the choice of firmware interface, it's whether the platform depends on hostile code. If you don't care about secure boot (or if you do but don't care about updating the validation keys at runtime), you can implement a functional UEFI/ACPI platform on x86 with zero SMM.
I appreciate your detailed reply. I think we are looking from different perspectives. You are correct in an item-by-item way, but you need to put them all together and see the bigger picture. In my comment, it may have made a mess confusing technologies and their capabilities, but I was looking at the forest, not the trees.
There are only two viable firmware alternatives in the world right now: ring 0 U-boot* or the ones that use ring -2: UEFI* and various bootloaders +TrustZone in Android world (read the footnotes!). Manufacturers usually focus on only one of the two: either ring -2 (locked bootloaders, UEFI +ACPI +SMM +whatever crapware they may want to add) protected by secure boot or ring 0 U-boot +a device tree +their GPL source code. The ones interested in locked-down platforms choose the ring -2 option and they are not going to make it open source, nor provide the signing keys to allow it to be replaced by FOSS alternatives.
I appreciate freedom. Linux kernel is free (ring 0). U-boot and coreboot are free (ring -2 if they include ACPI / SMM, else still ring 0). When I run a Linux kernel, I don't want it preempted and sabotaged by a ring -2 component. If that ring -2 includes proprietary blobs, then it's a hard "no" from me. You may argue that SMM (and ACPI) brings useful features such as overheating shutdown when the kernel froze/crashed or the system is stuck at bootloader, but let's face it: practically there's no free alternative to manufacturer's blobs when it comes to ring -2. The FOSS community barely keeps u-boot and the device tree working. Barely! An open source UEFI + all that complexity for every single board out there is a no-go from the start. If you ported Coreboot, i'm sure you know how difficult it is.
I recently learned that ACPI can be decompiled to source code, so that's an improvement, but not by much. Unlike a device tree, which is only a hardware description, ACPI is executable code. I see that as a risk and I'm not the only one. Even Linus had something to say about it - the quote is on wikipedia article. Some of that code executes in ring -2. It can also install components in the OS - spyware components - you can also read about that in the wikipedia article. U-boot has the capability of creating files on some filesystems and you can argue that a proprietary fork could maliciously install OS components by dropping something in init.d, but I've never heard of it being misused that way, and a manufacturer must publish the GPL source code, so it would be difficult to hide. A device tree can't to that at all. If you use UEFI, then every single blob published by the manufacturer must be decompiled and be inspected. U-boot + ACPI is probably simpler than porting Coreboot, but it still won't happen. There are simply too many systems to support.
So, as a conclusion. I see ring -2 as a dangerous capability (even if the malware itself doesn't execute in ring -2) because there are no viable open source alternatives. For this reason I encourage you to not support or promote UEFI and ring -2.
> Trustzone is strictly worse for user freedom than SMM is. This isn't an advantage for Arm.
> Trustzone is mostly deployed on Devicetree-based platform.
True, but ARM world still has unlocked CPUs that can boot unsigned firmware. There are none left in x86 world. (Or at least none that I know about.)
> No, the secure boot code that implements cryptographic validation of the OS is typically running in an entirely normal CPU mode.
OK, valid observation, I may have used "ring -2" to describe features that are not typically running in ring -2. I tried to avoid these technologies as much as possible and I don't have much hands-on experience about what runs where.
> you can implement a functional UEFI/ACPI platform on x86 with zero SMM.
One dev could probably implement and maintain one or maybe 5-10 systems if they are related (same CPU, mostly same hardware). How many systems are there and how many devs? Not possible, but for very very few exceptions, as long as some random dev got one of these systems for himself and does it as a pet project.
----
* When I say U-boot, I mean mainline U-boot plus a device tree, or forks with pubished GPL source code. I know U-boot can include ACPI and secure boot, but that's not what I mean in the context of this comment. Sure, you can set up secure boot with open source U-boot if you want to. There's nothing wrong with that.
* When I say UEFI, I mean all related technologies: ACPI, SMM, secure boot, signed firmware, etc. The whole forest.
You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.
UEFI switches the CPU into 32bit v86 mode or directly in 64bit mode and you can't go back to real mode without a CPU reset, which v86 won't allow (you don't have ring -2 privileges) and 64bit mode can't do at all. I don't have a UEFI system, so I might be wrong (I even hope I'm wrong - it would mean slightly more freedom still exists), but from what I read about it, I'm 90% certain it's not possible.
You're confusing several things here. The only x86 processor that didn't allow returning to real mode was the 16-bit 80286 - on all later ones it's as simple as clearing bit 0 of CR0 (and also disabling paging if that was enabled).
Nothing more privileged than ring 0 is required for that.
"v86" is what allowed real mode to be virtualized under a 32-bit OS. This is no longer available in 64-bit mode, but the CPU still includes it (as well as newer virtualization features which could be used to do the same thing).
Even if you could/can it is an anachronism. Architecturally there's just a huge difference between 8086 and even 80286 and the 386. Before the 386 I wouldn't touch a machine with an Intel processor in it. Once the 386/486 penetrated the market and became cheap it was game over for everything else because it was good enough (linear address space, memory protection, larger address space, 32-bit etc etc), smart enough, gosh darn it it was cheap and everywhere.
No, you are wrong. DOS COM files if 16 bit can't be run on 64 bit CPU's but 32 bit DOS binaries can be run under 32 bit GNU/Linux installs with DosEMU straight by just emulating the BIOS part, the rest is native.
Set seg_32bit=0 and you can create 16-bit code and data segments. Still works on 64 bit. What's missing is V86 mode, which emulates the real mode segmentation model.
50/50, because once you boot a 32 bit os you can run 16 bit binaries :)
I'm pretty sure that if I make a dual-kernel 9front (9pc and 9pc64 available at boot) in a 64 bit machine and I compile emu2 for it, DOS COM binaries might be trapped enough to run simple text mode tools under the 386 port.
> my worry is that ARM devices will bring an end to such an open platform like modern PCs are.
Modern PCs are NOT open platform anymore. Not since signed bootloaders, UEFI, secure boot. ARM on the other hand, as long as they don't require signed bootloaders (like phones) or a closed source driver for GPU or something, are in fact open.
You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.
I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .
And you're stuck with whatever fucked up kernel the vendor gave you, assuming they even followed their obligations and gave you access to the source. The vast majority of x86 systems run mainline kernels because there's a sufficient level of abstraction. The number of Arm devices that's true for is a tiny percentage of the Arm devices out there running Linux.
x86 always had standards: same two IRQ controllers, same UART chips, same keyboard controller, same PC speaker I/O, same ISA, same PCI, same AGP, VGA ROM that init the GPU with the same framebuffer address, all PATA controllers used the same I/O and IRQ and a single driver worked for all, same de-facto standards for audio (OPL aka. Adlib / SoundBlaster / MIDI), simple/bidi/ECP/EPP standards for parallel port and de-facto ESC/P standard for printers, etc. Hell, even USB there were only 2 at the beginning: Intel (UHCI) and AMD (OHCI), and then they cooperated and made universal EHCI.
ARM is a complete jungle by comparison. Each ARM manufacturer licenses a different UART, different USB, different PCIe (or none at all), different SATA, different GPU, different audio even if it's just I2s, different I2c, different SPI, different GPIO controller, different MMC/SDHCI, etc. etc. And each one needs, of course, a different driver!
The big mistake ARM (the company) made was to design only CPUs, not complete SoCs with peripherals, or at least require standard I/O addresses. And now they're trying to patch it up with UEFI and ACPI: closed-source ring -2 blobs that will never be updated or bug-fixed by any manufacturer.
> Shouldn't you manage permissions from groups instead of hacking udev?
Well my user is a member of plugdev, but by default udev has no clue that it should allow plugdev members to access some obscure third-party FPGA board. Someone has to write a udev rule for it, and if they don't share it for others to use, so does the next person. The next person happened to be me.
> And why do you have modemmanager if you don't have a modem?
And that is the right kind of question! I have absolutely no idea why my stock install of Linux Mint includes and activates ModemManager.
That's not the true word though, is it? It's an effort of capitalists the world over. And crucially, German government incentives when solar was still very expensive.
You should probably ask the parent commenter. I think GrapheneOS is a good choice even for those that don't have something to hide. Reminds me of iOS, really (in a good way).
reply