Hacker News Reader

Comment by tjoff | Hacker News Reader

The thing that stands out about ARM is that the user has less control of the hardware. The manufacturers try and succeed in keeping an extremely closed ecosystem.

Why would you want that? The Intel+AMD duopoly seems like nirvana compared to the Ampere and M1.

In fact, Ampere and M1 are a hint of the most dystopian future of computing I can imagine.

View on HN

Uh... M1 (at least when Mac-fused) isn't actually locked-down. You do have to jump through a few hoops to boot modified kernels[0], but it's a reasonable level of security for a chip primarily intended to go into laptops. There's an ongoing effort to reverse-engineer the M1 and port Linux to it[1], which has actually gone really well.

There's also plenty of ARM hardware out there that really doesn't bother with lockdowns. Raspberry Pi, for example, will happily boot whatever you put on the SD card[2]. There's also plenty of other dev boards and chips that are similarly not locked-down. The reason why people think of ARM as "more locked-down" is because it's more often used in locked-down hardware, but there's no architectural requirement for it to be this way.

The real big problem with ARM is that every chip is very different from one another. SoC designers have a habit of reassigning addresses and IDs on every new chip, with no thought towards backwards compatibility. So even if an ARM chip has no technical protection against third-party operating systems, any Linux kernel you build is unlikely to boot unless the SoC vendor has bothered to upstream support for it. Ironically, Apple is one of the few ARM vendors that actually does maintain backwards compatibility where feasible.

[0] The first admin account is granted possession of a local signing key that lets that user sign kernels. This means that you need to be able to log into that account under macOS in order to install Linux - evil maids need not apply.

[1] Legend has it that if you say "M1" three times in a HackerNews comment, you'll summon the primary developer of Asahi Linux.

[2] You do have to provide a GPU boot blob; no clue if there's a project to reimplement that.

> no clue if there's a project to reimplement that

There was! And it even booted Linux in some capacity: https://github.com/christinaa/rpi-open-firmware

> every chip is very different from one another

Eh, the usual embedded SoCs are not that different from each other — ARM GIC, ARM timer, lots of Synopsys Designware crap for SDMMC/XHCI/PCIe/etc.

For many SoCs it's totally feasible to make standards-compliant firmware, e.g. for the Rockchip RK3566 there is https://github.com/jaredmcneill/quartz64_uefi

And SoCs from the networking world (Marvell, NXP) are typically supported by upstream EDK2.

Oh, so I can buy an M1 for a custom board?

Are there several different manufacturers of motherboards for it?

There isn't even an ecosystem to talk about. The fascination about the M1 is quite disturbing. Unless you want to be locked into the apple store it has no value whatsoever. The energy put into running Linux on it is really impressive. But from a broad perspective nothing positive can ever come out of it.

It's a laptop chip. You can run linux and non-app store applications on it. If you don't want to use it - fine - but others are getting a lot of value out of it.

Yes?

And it's still a closed ecosystem.

This has nothing to do with ARM. Unlike the PC there is no standard for system architecture (including boards). ARM based designers like Qualcomm, NVIDIA etc can choose to have their own board and system architecture. For example, they can boot of any memory location or lock the user out of using an exception level like EL3/EL2 etc. That is why the ecosystem looks closed. Nothing stops a SoC designer from giving complete access to hardware.

BTW - any SoC designer that uses RISC-V can do the same.

... and as long as that remains true it is the most user hostile general purpose platforms we've come up with.

It should not be celebrated. Or we will fix the mistake that is the PC forever.

There are standards like the Arm Server Base System Architecture but companies don't have to follow it. Most of the ARM servers are custom things for big datacenters. As you said the smaller systems like phones and other embedded systems have their own boot systems and memory layout etc.

https://en.wikipedia.org/wiki/Server_Base_System_Architectur...

https://developer.arm.com/documentation/den0029/latest

In the server space, there is no good reason to do weird unusual things → even e.g. the "custom" AWS hardware is as standards-compliant as possible (if you look at the ACPI tables on an a1.metal instance, you'll only find an AMZNxxxx device for the PCIe host controller, and that's only because Synopsys Designware IP sucks^W has a stupid hardware bug related to filtering that requires a little workaround quirk)

Any architecture that forces something like the Intel Management Engine on users is closer to dystopia than nirvana.

Absolutely. Whether it's ARM-based or RISC-V, nothing will stop high-end SoC vendors from developing closed hardware blocks or firmware, especially if they have customers from the DRM space (CA vendors).

> In fact, Ampere and M1 are a hint of the most dystopian future of computing I can imagine.

OK I'll bite. What aspect of Ampere is locked down? They are nothing like the bad closed-source hacks that we see in small development boards.

I apologize. I confused Ampere with Amazon's Graviton.

AWS offers Graviton instances in a bare-metal way too, so you can see for yourself what the SoC offers. It's quite clean, there is a Designware PCIe filtering quirk (same as on e.g. the Marvell Armada8k) but other than that it's SBSA-style UEFI+ACPI. Very standard system.

In terms of firmware openness, yeah, you don't get the firmware source, but you don't get to touch the machines physically either so you wouldn't have a chance to run a custom build anyway :D

(While Ampere Altras are supported by upstream EDK2, have fun)

Where do you buy Graviton CPUs or systems, then? Their official website[0] only seems to mention renting them on their premises.

[0]: https://aws.amazon.com/ec2/graviton/

I did just say that "you don't get to touch the machines physically either".

What does being able to buy them have to do with.. anything?

The concept of renting a VM is not new. The introduction of processors that a VM hosting company designs exclusively for use on that service is, and the comments in the thread above seem to imply a fear of this causing some kind of lock-in or whatever. What I'm saying is, this is completely unfounded fear. Graviton instances are very much standard machines and you can run the exact same OS images on there as you can on an Altra or a HoneyComb LX2K or a MACCHIATObin. (Yeah, the OS needs a driver for Amazon's network card, but mainline Linux, FreeBSD and NetBSD have that.)

>AWS offers Graviton instances in a bare-metal way too, so you can see for yourself what the SoC offers.

Oh, we should be so grateful...

Or perhaps be happy with what we got and not sacrifice everything for some very short term 5% benefits?

How exactly do you sacrifice ANYTHING compared to any other VPS rental?!

By supporting closed ecosystems designed to take away power from you?

Take one guess.

What closed ecosystem?

Nothing becomes any more closed if you switch the ISA of the CPU used in your VPS to aarch64. The only closed ecosystem here is AWS itself, but what takes power away from you is using non-EC2 services like DynamoDB.

In fact the Arm ecosystem is way more open, because there are SoCs that can run completely blob-free firmware (e.g. from Marvell), which is just not happening with any modern Intel/AMD system.

Hardware.

A firmware-blob is nothing in comparison for the vast majority of cases.

Can you elaborate? I don't understand what you mean.

Reply on news.ycombinator.com