AMD supports ECC on their consumer chips, but without Intel support it's never taken off and some motherboards don't support it, or if they do it's not clear in the documentation. I do use ECC RAM on my Threadripper machine and it does work, but I had to look for third party info on whether it would and dig around DMI and EDAC info to convince myself it was really on. It also makes it safer to overclock RAM since you get warnings when you're pushing things too far, before outright failures. And it helps with Rowhammer mitigation.
Apple M1s don't do ECC in the memory controller as far as I can tell, but at least they have a good excuse: you can't sensibly do ECC with 16-bit LPDDR RAM channels. There's no such excuse for 64/72-bit DIMM modules. I do hope we work out a way to make ECC available on mobile/LPDDR architectures in the future, though. Probably with something like in-RAM-die ECC (which for all I know might already be a thing on M1s; we don't have all the details).
Intel has offered ECC support in a lot of their low-end i3 parts for a long time. They’re popular for budget server builds for this reason.
The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC requires more chips, more traces, and more expense. Consumers can’t tell if there’s a benefit, so they skip it.
> AMD supports ECC on their consumer chips, but without Intel support it's never taken off
You’re blaming Intel’s CPU lineup for people not using ECC RAM on their AMD builds?
Let’s be honest: People aren’t interested in ECC RAM for the average build. I use ECC in my servers and workstations, but I also accept that I’m not the norm.
I'm blaming the decade+ of Intel dominance for killing any chance of ECC becoming popular in non-server environments, just as RAM density was reaching the point where it is absolutely essential for reliability.
> The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC requires more chips, more traces, and more expense. Consumers can’t tell if there’s a benefit, so they skip it.
Motherboard traces are ~free and the feature is in the die already, so it requires zero expense to offer it to consumers. Intel chose to artificially cripple their chips to remove that option. Yes, I know there are a few oddball lines where they did offer it. They should have offered it across the board from the get go, seeing as they were selling the same dies with ECC for workstation use.
OTOH, it shouldn't be significantly more expensive. It should be ~9/8 the cost of regular memory. It's just one extra chip for every 8. Nothing more.
(in-band ECC is present on Elkhart Lake Atoms and on Tegra Xavier for example)
I disagree. AMD has offered ECC support for a while and it’s not catching on. It doesn’t make sense to blame this on Intel.
> Motherboard traces are ~free and the feature is in the die already, so it requires zero expense to offer it to consumers.
Yet it’s missing from a substantial number of AMD boards, despite being supported. You have to specifically confirm the motherboard added those traces before buying it.
Traces aren’t entirely free. Modern boards are densely packed and manufacturers aren’t interested in spending extra time on routing for a feature that consumers aren’t interested in anyway.
Or they just don't care because it's not already popular and unbuffered ECC RAM isn't even particularly widely available. The delta design cost of routing another 8 data lines per DIMM channel is tiny. Especially on ATX boards and other larger formats. I could see some crazy packed mini-ITX layout where this might be a bit harder, but definitely not in the normal cases.
(I've routed a rather dense 4-layer BGA credit card sized board; not exactly a motherboard, but I do have a bit of experience with this subject. It was definitely denser than a typical ATX board per layer.)
Every time I've gone looking for unbuffered ECC RAM over the past three or five years, I've had no trouble finding it. In my experience, the trick is to shop for "server" RAM, rather than "desktop" RAM.
Are there speeds or capacities here that you'd particularly like to see that aren't present? <https://nemixram.com/server-memory/ecc-udimm/>
I've been quite satisfied with the three orders that I've placed with Nemix. I see no indication that they _don't_ ship to Japan, and indications that they _do_ ship internationally... so consider purchasing from them next time you have a need for such memory.
Or, hell, I'd be _shocked_ if there wasn't a company in JP or or KR or CN that also does what Nemix does (that is, yank RAM from decommissioned servers, test it, and sell the stuff that's solid).
And, with Ryzen (and Ryzen Threadripper) becoming ever-more popular, I would expect ECC RAM to continue to drop in price when compared to non-ECC RAM. (But, let's be real here, when you spread the price out over five or ten years, it's _totally_ worth it to have RAM you can rely on.)
It does make sense. Imagine if only 50% of web browsers supported a feature, would you implement it in your website?
Point being, the low market share of ECC-compatible setups means that the market demand for ECC is low, which means that the selection is low, which means the prices are higher than they could be. So yes, absolutely Intel has contributed massively to the issue.
Intel removed ECC support in the 10th gen so you have to go for Xeon nowadays.
Yes. ECC was standard on first IBM PC 5150, on PS/2 line, on pretty much all 286 clones etc. Intel killed ECC on the desktop when moving to Pentium, prior to that all of their chipset products (486) supported it. 1995 artificial market segmentation shenanigans https://www.pctechguide.com/chipsets/intels-triton-chipsets-...
In the absolute the cost of ECC everywhere would not be substantially greater than the prices we have now without. The current ECC prices are high because it is not broadly used, and not really the inverse. Consumer skip it because it is fucking hard to get ECC enable parts for S SKUs (or H / U) in the current situation, while there are plenty of non-ECC vendors and resellers, and something like at least 3 times the number of SKUs. And consumers have not been informed they are buying unreliable shit.
I think computers are now so important to our life, we need to start regulating them like we do cars.
Start seriously slapping companies that deliberately or negligently release equipment with obsolete kernels and security holes, mandate ECC like we mandate ABS, mandate part avaliability for 10 years like we do with cars, etc.
Every day we let this this slide, thousands of people loose precious data and number of 'smart' toasters mining crypto increases.
Think about how many laptops ship with Wi-Fi whitelists with the excuse of "FCC certification". It doesn't matter that the FCC doesn't actually prohibit users from swapping out Wi-Fi cards; manufacturers will do it anyway.
And not just storage - the main memory bus is the only data bus in a modern computer that doesn't use some form of error correction or detection. Even USB 1.0 has a checksum. So everywhere else we use ECC/FEC or at least a checksum, be it PCIe, SATA, USB, all storage devices as you mentioned rely heavily on FEC, all CPU caches use ECC. Except the main memory and its bus. Where all data is moved through (eventually). D'uh.
[0] https://www.revk.uk/2017/12/its-official-adsl-works-over-wet...
Not literally wet string, but definitely low tech. ADSL is special though, not many technologies can literally run over wet string :-)
Of course we do: workstations.
It's cheaper, that's why it isn't everywhere.
And now the next desktop consumer upgrade I purchase will be AMD and will have ECC (well... unless it's way more expensive).
However I would say avoiding Intel completely is unnecessary. They're a good FOSS citizen when it boils to things like WLAN and GPU.
Its just that with AMD, you can hardly go wrong on CPU and GPU side. Especially on Linux.
And they - rightly - get plenty of flak for it.
As soon as you want to use Linux or macOS or Proxmox or anything, prepare for trouble. Its just not a FOSS-friendly company.
Even on the Nvidia Shield TV (a great bang for the buck) they added commercials in the new UI. Though one might attribute that to Google, it is the only Nvidia device I bought past 5 years. And the only one which got a feature downgrade (or upgrade with a feature I don't want/like).
With regards to Intel I remember my 4770k not having a specific feature (IIRC for hardware virtualization) which all non-k series had. And I found that out too late.
It even works with multi-screen setups and using the rest of the memory for CUDA.
You don’t get flipped off by Linus T for having good drivers. You also don’t have to wait years for wayland to work if your driver is good.
Maybe I've just been lucky but over all that time not a single glitch. The main gripe I have with them is having you jump through hoops to be allowed to download certain libraries. That's just a complete nuisance. And I think their TOS are unethical.
The NVIDIA driver on Linux is extremely good and in my experience of better quality than AMD, but sorely lacking in modern features such as Wayland support. We still don't have decent hardware encoding nor raytracing support on AMD, the champions of free software, while DLSS and NVENC have been running on Linux for a while now.
I run AMD GPUs now but I'm quite done with the NVIDIA hate boner the Linux world has.
They'd have to license TB from Intel. I don't know about TB4, but TB3 is royalty-free, just gotta pass a certification.
TB3 or better would be great for eGPUs in general. Not sure I personally would need TB4.
Also, I wonder if Framework would be usable with say Proxmox and macOS (or 'native' Hackintosh?)
What does tb4 offer over 3?
The short answer for Thunderbolt 4 over Thunderbolt 3 is "a second 4K display" thanks to double the PCIe bandwidth, 16Gbps vs 32Gbps. (The main data channel is 40Gbps in both.)
USB 4 is actually a bit more constrained than Thunderbolt 3, at 20Gbps data channel, and no guarantee of PCIe bandwidth.
> Thunderbolt 4 guarantees support for one 8K display or two 4K displays. A USB4 port can only support one display with no mention of resolution minimums. And even that isn't required as some USB4 ports will not support video at all.
Finding it hard to keep up with tech lately :D
I got 2x 1440p monitor and won't upgrade either any time soon. So I suppose if I were to use both of these, I'd be fine with TB3 and eGPU?
It's mostly the same though and devices should be cross-compatible.
Primarily you want TB4 for the stricter requirements for certification.
Except you cannot disable AMD PSP.
Then again everything I think that way about is apparently a mortal sin in the business world.
Personally, I don't care much about firmware being proprietary, if it cannot be used to meaningfully change the functionality of the chip. But I do care about the chip ultimately following a public specification. I want an ISA just like x86, ARM, or RISC-V. Tell me the size and format of the ring buffer I must write to or read from, and I'll program the rest.
But even that is still too much to ask for apparently. Graphics cards are getting closer with lower level drivers like DX12 and Vulkan, but we're not quite there yet.
My biggest problem is that figuring this state of affairs out is like pulling teeth.
Besides, there are other ways to get that flexibility. CPUs for instance have a very flexible ISA: even if they’re set in stone, we can use them for pretty much anything, the only real limitation being performance.
Now when I think about it, even if firmware can significantly change the functionality of a chip, I don’t care too much of it being proprietary. Not more than I care about fixed hardware being proprietary. It’s okay for a piece of hardware to have 3 or 10 different configurations, as long as (i) I can trust that each configuration works as advertised, and (ii) the ISA I got from each configuration is publicly documented.
There’s a practical reason for this wish: hardware is typically orders of magnitude more reliable than software. That’s mostly because buggy software is easily updated, while flawed hardware is often impossible to sell. CPU bugs do happen, but they’re sufficiently few and far between that when my programs behave unexpectedly, I can safely assume it’s the software’s fault.
I don’t want drivers any more, I want the hardware’s manual. https://caseymuratori.com/blog_0031
Most of us here think of copyright in the way Disney or Nintendo thinks of copyright: we own the thing, and you don't get to touch the thing. However, to actually get 100% ownership over a copyrighted work, you actually have to make 100% of the work. If you're just buying what you need to make the thing work, then your ownership over the resulting software is going to be thin. After all, the people who sold you the software are going to want to be able to sell it to other people, and in order for that to work, those other people need to not have the software. Which means that all those licenses are going to have provisions on further redistribution so that they still have their copyright monopoly.
If you want to release source, then you have to go back to everyone you bought software from and renegotiate licenses on a far more expensive basis. Because you're asking them to take all the money they will ever make on that software all in one go. For similar reasons, things like licensed music tracks in games are far cheaper if the license is for a limited time, because then the record label can ask for more money later on. The irony of proprietary software development is that it can actually be just as collaborative as Free; but only if every participant regularly pays back into the system.
In contrast, the Free Software world tends to have some of the strictest copyright hygiene in any software industry. You have to, because the whole point is to more or less waive copyright interest in the code - and to do that, you need to have Disney-level ownership over everything. We can thus look at copyright as a sort of deliberate cultural poisoning that puts software developers and artists into the position of having to demand troll tolls everywhere.
Libreboot disagrees with that: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-....
Also, FSF would never endorse an Intel CPU with disabled Intel ME. It must be fully removed to get the RYF certification.
Except it relies on proprietary drivers, which will not be updated by the vendor, resulting in a brick after some years. Librem 5 and Pinephone will receive software updates forever.
> But you're bound to old, refurbished ones (X230/T430 apparently) [1].
Not necessarily: https://forum.qubes-os.org/t/community-recommended-computers....
> Librem 5 delivers awful performance
What do you mean? It can run 3D games and provides full desktop mode. What else do you need?
Ah yes, that phone where the FSF told them they had to move a blob from the bootloader into an external Flash memory and load it through two layers of CPUs, because going through that pointless dance magically makes it Free™ (read: hidden enough that users won't notice so they won't realize they're still running a blob as part of something as critical as making the RAM work).
Also that phone which runs a pile of other giant blobs, including the USB-PD controller and the baseband, of course.
The baseband is on the upgradable M.2 card, also has no access to anything. It can even be killed with a hardware switch. The best smartphone you can find if you care about it. Nobody says that other blobs are fine, but it's already a huge step to the freedom.
The proprietary software literally configures the RAM on the phone. It is critical for making the RAM work, of course it has access to the RAM! Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
But they added an extra two layers of indirection, even though the blob ends up running on the same CPU with the same privileges in the end anyway, because all that obfuscation let them get in via the FSF's "secondary processor" exception somehow. Even though the end result is the same, and you're still running a blob to perform a critical, security-relevant task.
If the goal is security ("blobs can't take over my system") and stuff running during the boot process doesn't count, then Apple's M1 machines are on precisely the same level as the Librem 5: they also run blobs on boot, and at runtime all remaining blobs on separate CPUs are sandboxed such that they can't take over the main RAM/CPU.
> Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise.
> even though the blob ends up running on the same CPU with the same privileges in the end anyway
This is not how I understood it. The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core. From here: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
It absolutely wasn't. Look into it. In every case, the blob ends up running on the RAM controller CPU and supposedly finishes running and is done. The whole point of the exercise was obfuscating the process which is used to get to that point such that it avoided the main CPU physically moving the bits of the blob from point A to point B. Really.
> This is not how I understood it. The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core.
That is incorrect (great, now they either don't know how their own phone works or they're lying - see what I said about obfuscation? It's great for confusing everyone).
The M4 core code is not proprietary; it's the pointless indirection layer they wrote and it is not loaded from that SPI NOR flash. It's right here:
https://source.puri.sm/Librem5/Cortex_M4/-/tree/master
That open source code, which is loaded by the main CPU into the M4 core, is responsible for loading the RAM training blob from SPI flash (see spi.c) and into the DDR controller (see ddr_loader.c).
The actual blob then runs on the PMU ("PHY Micro-Controller Unit") inside the DDR controller. This is an ARC core that is part of the Synopsys DesignWare DDR PHY IP core that NXP licensed for their SoC. Here, cpu_rec.py will tell you:
firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin
full(0x5ac0) ARcompact chunk(0x4e00;39) ARcompact
https://github.com/u-boot/u-boot/blob/master/drivers/ddr/imx...
Same code, just running on the main CPU because it is absolutely pointless running it on another core, unless you're trying to obfuscate things to appease the FSF. And then the blob gets appended to the U-Boot image post-build (remember this just gets loaded into the PMU, it never touches the main CPU's execution pipeline):
https://github.com/u-boot/u-boot/blob/master/tools/imx8m_ima...
Purism went out of their way and wasted a ton of engineering hours just to create a more convoluted process with precisely the same end result, because somehow all these extra layers of obfuscation made the blob not a blob any more in the FSF's eyes.
The security question here is whether that blob, during execution, is in a position to take over the system, either immediately or somehow causing itself to remain executing. Can it only talk to the RAM or can it issue arbitrary bus transactions to other peripherals? Can it control its own run bit or can the main CPU always quiesce it? Can it claim to be "done" while continuing to run? Can it misconfigure the RAM to somehow cause corruption that allows it to take over the system? I have seen no security analysis to this effect from anyone involved, because as far as I can tell nobody involved cares about security; the whole purpose of this exercise obviously wasn't security, it was backdooring the system into RYF compliance.
Who's "they"? This is an unofficial community wiki.
I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote (https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...) that 'the M4 is the “secondary processor” that handles the blobs', and I conflated "handles" with "executes".
However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules, and Ainslie's article on the Purism web site and Nicole Faerber's talk (https://media.ccc.de/v/Camp2019-10238-a_mobile_phone_that_re...) both explained how Purism is using the secondary processor exception in the RYF rules.
It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5. Raptor Computing is now facing the exact same problem with the proprietary Synopsys DDR4 timing blobs in the POWER 10 processor, so this is actually a common problem with most modern processors. It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works.
Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world and make the Librem 5 no different than an Apple device with an M1 processor, which is literally a black box. Forget the fact that the L5 is the first phone to have free/open source schematics since the GTA04 in 2012 and we know the 1267 components on its PCBs, plus we have 7000 pages of documentation for the i.MX 8M Quad processor, and everything is running free/open source drivers.
There is only so much code that you can hide inside 58 KB of blobs and that early in the boot sequence, you can't rely on anything else being operational in the device, so you would need to have all the code to initialize and control components on the phone. Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world. It isn't hard to verify that the blobs that are stored inside the L5's SPI NOR Flash chip are the same ones being distributed by NXP, so then you are left with the theory that NXP or Synopsys are distributing blobs that do something malicious, which would be suicidal for either of those companies if anyone ever discovered it. Supermicro's stock lost 40% of its value after Bloomberg published one story about the Chinese government inserting spy chips in Supermicro motherboards, and nothing in Bloomberg's article was verifiable. Companies like NXP and Synopsys are very unlikely to risk their businesses, even if the NSA asks them, so I find the whole scenario far-fetched.
> However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules
The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think it does, and the FSF have shown zero interest in educating users about what it means and doesn't. It is a feel-good program that actually hurts the ecosystem behind the scenes. Why is Purism lending it legitimacy by attempting to get certification?
They should've done what bunnie did after Stallman showed up with that crazy "fuse the GPU off" idea: give up on this nonsense and focus on delivering a device as free as possible, instead of wasting engineering time pandering to a program that isn't helping anyone.
> It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5.
Indeed, and this is the crux of the problem: 100% libre modern hardware is impossible in the current world, but the FSF and people who buy in to their tactics keep pretending it is. That there is some magical line that denotes a device as "freedom-respecting" and they can just put things in that bucket and slap a sticker on it and sell it to all those freedom fanboys. This encourages further ignorance: users don't have to think about practicalities such as what security risks are actually present or what the lack of source code for some components might do to affect things they might practically want to do. They don't have to think about whether things are signed or validated, or how to verify that they are running software that is at the very least trusted to be a widely available build, or anything like that. They just see "no blobs in my filesystem!" "freedom!" and declare that device as a Friend of Free Software. And then they extrapolate from that a bunch of properties that are absolutely not implied, around privacy and security and more.
> It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works.
Purism did a decent job with the hardware; the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.
> Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world
Oh, they absolutely don't. In practice they don't; they also do not present any practical restriction on freedom. Even if the training code were open, I bet there isn't a single person who would ever modify it on a shipping device (especially one with soldered RAM). That's the kind of thing you need 6-figure test equipment to validate properly, and there is no reason to go mucking with it for any end user of the hardware. It existing as a blob causes zero reduction in practical freedom for users, because source code for it would only give you theoretical freedom that nobody wants or needs to exercise.
But you see, the entire FSF culture isn't about practicalities. That's the whole problem with it. It is about platonic ideals and philosophical arguments, and completely eschews looking at how real people are affected by software being open or closed. And from that point of view,
> and make the Librem 5 no different than an Apple device with an M1 processor
They indeed make it no different, because in both cases you're running blobs on boot, and you're in the same practical situation from an absolutist point of view, modulo the FSF's backdoor arguments.
> which is literally a black box.
How so? The i.MX8M is also a black box by that token; it's a pile of silicon. Sure, it may be (partially - those SoC programming manuals always have censored parts) documented, but it's not open hardware. You can't know what it does precisely. You can't prove the absence of a backdoor any more than you can with the M1.
> Forget the fact that the L5 is the first phone to have free/open source schematics
I have schematics for some of my M1 Macs. Sure, they leaked and were not willingly published... but in the end, I have them and can look things up in them. So for analysis/educational intents and purposes, I'm in a similar situation as you are with the L5.
(Of course it makes a difference in corporate goodwill that Purism published them deliberately; I'm just pointing out that you're limited to that aspect, since at the end of the day, we both have schematics for our devices, so we're both in the same situation as far as being able to understand them).
> and everything is running free/open source drivers.
We're working on that for the M1. You can run Linux on the M1 today with fully free/open source drivers for most critical parts of the hardware. This blog post has a table of hardware support and upstreaming status:
https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally.
I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020. And that was working from scratch, on an unknown SoC, reverse engineering everything, having to make more intrusive patches to Linux because this SoC is quite "special", having to write our own pre-bootloader from scratch, etc. A year after release, we have a bunch more hardware working and on the way to upstreaming, including sound on the Mac Mini, I2C, SPI, NVMe, keyboard/trackpad on the laptops, USB and USB-C, power management, basic screen/display controller support, Wi-Fi (including on prior Macs going back to 2017), and support for 9 distinct hardware platforms including the just-launched M1 Pro and M1 Max models, which were already at feature parity a few weeks later. Given all that, I'd say we're doing a lot better with M1 upstream support with fully free drivers than Purism did, timeline-wise. And we didn't need a SoC programming manual. Maybe it's because we aren't wasting time trying to get RYF certification? :-)
Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work.
> Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world.
The M1 is in that situation too: Apple's bootloader is bare-bones and doesn't even support USB, let alone networking (by design). The Wi-Fi firmware is larger than the first-stage and second-stage bootloaders put together. The whole thing boots too fast to go around initializing Wi-Fi (just firmware upload and boot takes a few seconds on these modules...) and associating to a network and phoning home. And due to the SoC design, after boot, no proprietary code remains running on any secondary core with the ability to take over the system; all auxiliary cores running firmware are sandboxed behind IOMMUs, and the main CPU does not have the ability to run a secret supervisor/hypervisor under the OS (it can run a hypervisor but that cannot be done surreptitiously and silently; the guest knows).
And of course, given how Apple is constantly under attack by nation-state-sponsored entities like NSO, they have every incentive to fix security problems and build systems that are very difficult to compromise. To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might), nor does it make any attempt at being secure against physical access attacks (e.g. evil maid). The M1 does. I can install my own Linux bootloader, which requires entering my machine owner credentials, and know that nobody else can take over the device without wiping storage entirely via DFU mode, even if they have physical access, at least not without Apple's help (and even then there's ways of hardening that, but we're still working on the details). And I still don't have to delegate all my security to Apple; I can still use full disk encryption and know that even if they reboot the device to take over the boot process, they won't be able to get at my data.
This is not to say the M1 is a security panacea and the L5 is terrible. They each have their pros and cons. Some people might prefer one, some people might prefer the other. That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.
For the record - we have some changes for this driver in our downstream tree waiting to get upstreamed (some may need to be reworked though): https://source.puri.sm/Librem5/linux-next/-/commits/next/byz...
I get the frustrations behind it, but its harmful. Its unfair to advocate for others to not use/buy a device because it doesn't fit their perfectionist specifications, while the project made a substantial effort and should be judged on the incremental improvement instead. More so, when they its a unique project which is far ahead of the competition.
What happened though, with regards of that extra layer, is akin to the glue Nvidia uses for their proprietary driver. Its akin to greenwashing. Its dishonest, and unnecessary. Its a marketing ploy. Yes, we should criticize companies for such behavior. No, it does not mean the entire product (or company) is terrible.
However, there are people in the FSF who recognize this. See the comments of Leah Rowe (the Libreboot maintainer) about the problems with the RYF criteria: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... (read her comments in the libreboot policy she linked to)
I have also criticized the binary nature of RYF certification and suggested that it either needs to move to a category based system: https://forums.puri.sm/t/does-respects-your-freedom-certific... or a number score system: https://forums.puri.sm/t/does-respects-your-freedom-certific...
> That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.
I largely agree that RYF has problems, but it isn't useless, since it does tell people that they can install a new OS or upgrade it without having to deal with proprietary blobs. However, if people want to upgrade the firmware, a RYF device makes that very inconvenient, because you can't just stick the new firmware in the /lib/firmware directory, but have to follow an awkward procedure to upgrade each component's proprietary firmware, and the RYF rules are unclear about whether those upgrades are even allowed. I have written repeatedly to the FSF asking for clarification on whether proprietary firmware can be upgraded under the RYF rules, and I have never received an answer. See: https://forums.puri.sm/t/does-respects-your-freedom-certific...
It's worth mentioning that Purism intends to provide firmware updates for the L5 and has already posted instructions upgrading a couple components: * Texas Instruments TPS65982 USB Type-C and Power Delivery controller: https://source.puri.sm/Librem5/firmware-tps6598x-nonfree * Silicon Labs RS9116 WiFi/Bluetooth: https://source.puri.sm/Librem5/redpine-firmware-nonfree
However, I would agree that the RYF certification isn't useful for distinguishing whether the PinePhone's firmware is more free than the Librem 5's firmware. In fact, it can be argued that the PinePhone has inspired a lot of community work to replace parts of the EG25-G modem's proprietary firmware, so the PinePhone will potentially have a freer modem than the Librem 5.
RYF also has nothing to say about the freeness of your hardware. For example, the MNT Reform provides all its sources for the design of the hardware, so anyone can legally make it, whereas Purism has released the PDF files for the L5's schematics, and the STL files for its case, but won't release the original design files for the boards and case until it recovers its development costs. PINE64 releases the board schematics as PDF files, but they have a normal copyright, so no one can legally reuse or modify them. If you want to do board repair, however, you need to know the placement of each component on the board, and neither Purism nor PINE64 have released board views, whereas board views are leaked for most Apple devices.
> the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.
It seems that you want to throw the baby out with the bath water. In my opinion, the basic goals of the FSF need to be supported. The problem is the strategy that the FSF uses to reach those goals and its specific policies. I want to see a world where ordinary people can control the technology that they rely on, rather than technology being used as a means to control people.
As I see it, we got lucky with the x86 architecture, because Intel and AMD used a standard booting procedure which wasn't locked, so it was possible to install our own OS on almost any PC in the past, but as PCs move to ARM, I fear that every company is going to copy Apple in designing their own ARM processors for PCs, which have custom booting procedures. Maybe Qualcomm, Samsung, MediaTek, UNISOC and all the rest who are reportedly designing custom ARM processors (Google, Xiaomi and Oppo) will release their files or share info, but I suspect that many PCs in the future will be like the Apple A-series processors where we can't install Linux.
In my opinion, the best strategy to avoid this dark future is to support the device makers and component makers who support free/open source software, rather than continuing to buy products from companies that don't share our goals. Apple sued Corellium (and thankfully lost in court), which is a good indication of Apple's attitude toward its users. When we buy Apple products, we give more resources to a company that is openly hostile to users being able to control their own hardware.
While I have specific criticisms of the RYF, I want the RYF certification program to be reformed so it is useful in the real world, because I do think that people who care about FOSS should be giving their money to companies that support their goals, because that is the best way to create a sustainable industry in the long term that respects user rights and are willing to work with the community. Giving our money to companies like PINE64, Purism, Lulzbot, OLIMEX, Raptor Systems, Arduino, MNT, etc. helps build up our leverage, because these companies will have more power to make demands of component suppliers.
NXP has positioned itself as the best ARM manufacturer for the Linux community (ahead of Rockchip), whereas I rank Apple as the second worst (although today I would now place it as the third worst ahead of UNISOC and HiSilicon). See: https://forums.puri.sm/t/concerns-about-the-security-risk-of...
I know that the Librem 5 doesn't have great performance compared to a phone based on an A13 or Snapdragon 888 (see my benchmarks: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...), but I bought the phone anyway, because I know that Purism went out of its way to select component manufacturers who support FOSS. NXP makes commits to mainline Linux to support its i.MX processors, and releases documentation to the community without NDA's. Silicon Labs (formerly Redpine Signals) releases the drivers for its WiFi/Bluetooth chips under the GPL 2 and altered its firmware at the request of Purism so it didn't have to load the firmware from the main Linux file system. By giving money to Purism, NXP and Silicon Labs, I'm helping to build up a better supply chain, so there is more hope of getting hardware in the future that respects our digital rights.
x86 situation is actually horrible. Not only there are SMM interrupts that are continuing to execute firmware code outside of OS control, it also has proprietary security processors running signed code (ME/PSP) with potentially unlimited access to main memory. M1 fares much better in category of "amount of proprietary code running that might affect your security": no firmware code running at all on the main CPU after bootloader passes control to the OS, and all coprocessors are safely gated behind IOMMUs.
As for other ARM PC consumer devices, they will probably use whatever Windows requires to boot, which is UEFI + ACPI.
Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."
Having said that, I don't think that your criticism of Purism's kernel work is very fair. Purism made its first commit to mainline Linux for the Librem 5 in July 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Purism submitted the device tree for the Librem 5 DevKit to mainline Linux on June 17, 2019 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), which was 7 months after it started shipping the DevKits in mid-December 2018 (https://puri.sm/posts/2018-devkits-are-shipping/). I can find emails from Purism trying to submit the device tree for the Librem 5 since May 25, 2020 (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/00715.html), which was 7 months after it started shipping on Nov 17, 2019. Since Linux version 4.20, Purism has made roughly 150 commits to mainline Linux to support the Librem 5, whereas System76 has made 13 commits to the Linux kernel (https://blog.system76.com/post/667593198841069568/open-up-co...) and TUXEDO Computers has made one commit (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...), and I can find commits for the rest of Purism’s competitors (PINE64, Juno Computers, Slimbook, ThinkPenguin, F(x)tec, Planet Computers, Hallo Welte, etc.)
You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.
You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.
By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).
> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)
The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.
More like deliberately modified their design to allow it.
>Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017
I don't think Corellium did have much effect on the Asahi upstreaming effort, they just posted haphazardly patched up kernel tree which they were using for validation of their virtualization platform. Majority of their patches weren't suitable for upstream submission.
RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually actively harmful to freedom, as it encourages manufacturers to hide blobs to get through its backdoors (ROM blobs are OK, RAM blobs are not), when doing the opposite is actually more accountable and open, and allows for user-controlled replacement of blobs with free versions in the future.
Also, Stallman had personally said he wouldn't give the Novena open hardware laptop RYF certification unless they permanently fused off the GPU, "because otherwise users might be tempted to install the (optional, not distributed with the product or endorsed in any way) GPU blobs". Literally the same product segmentation nonsense we're bashing Intel for here. This was before open drivers became available, which they eventually did. Imagine how wrong the situation would've been if bunnie, the creator of Novena, had actually listened to this; "RYF" certified Novena owners would own crippled machines unable to use 3D acceleration, while the rest would own machines capable of running a 100% libre desktop including 3D acceleration.
> Libreboot disagrees with that
You do realize that that post is Leah politely saying that RYF sucks and is completely broken, and she's given up on strict compliance, right? FSF policy is indeed that you shouldn't upgrade your microcode (see e.g. endorsing linux-libre, which censors kernel messages telling you about important microcode updates).
This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem.
This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).
So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.
Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software.
> Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.
Yes, I'm saying that. But if you intentionally prevent users from updating it, then it does not turn software into hardware in my opinion.
Do you have any link saying that the blobs are still being executed on the main CPU after the RAM training is finished? Upd: you replied here: https://news.ycombinator.com/item?id=29842166.
There is a distinction between blob 'is in ROM and cannot be updated', 'is in EPROM and might be updated', and 'it is in RAM and must be provided at boot'.
While one can argue about the second case, the third case is problematic for practical and legal reasons, as handling (using and distributing) requires accepting licence of the firmware, which affects distribution infrastructure of free Linux distributions. Some firmwares also do not allow redistributing, so they have to be downloaded from vendor website, which further complicates practical and legal matters and have privacy issues.
The second case (it is in EPROM nad might be updated) does not have such effect directly, but leads to it indirectly, by allowing vendors to depend on cheap post-purchase fixes by firmware update, so they can offer less tested products, where firmware update is practically necessary due to original firmware being buggy, so essentially moving to the third case.
i just can't wrap my hands around macOS and I used to work at apple. I'm just so used to linux for everything.
- forbidding motherboard manufacturers to implement backward compatibility
- PCIE 4 and 'PCI Express Resizable BAR' CPU features linked to the price of northbridge
The efficiency cores don’t have AVX-512 because they’re low power, simplified cores.
This mod required disabling the efficiency cores, reducing core count anyway. It wasn’t actually a free upgrade.
> I much prefer AMD's strategy of segmenting just by speed and number of cores
I’ve been using ECC RAM with AMD consumer parts, but it’s not all smooth sailing. The ECC support in their consumer parts isn’t officially supported, so it has been extremely difficult to determine if it’s even working at all. There are long forum threads where many people have tried to confirm it with mixed results. AMD may unofficially leave these features in place, but it turns out unofficial support isn’t all that straightforward.
If you run Linux, you can use dmidecode and the EDAC driver to confirm if you have ECC enabled.
I put it in an Intel-branded motherboard as well, and that turned out to be one of the few motherboards I've had that failed prematurely.
Since then, the only Intels I've bought since then have been used ThinkPads.
I know the explanation in some cases were that they didn't pass QC, but I also never came across stories of widespread problems when these cores were reenabled by end users.
If Intel is playing games here, I'm not sure they're unique to Intel.
[0] https://www.techradar.com/news/computing-components/processo...
[1] partial list of prior unlockable AMD chips: https://docs.google.com/spreadsheets/d/19Ms49ip5PBB7nYnf5urx...
The reason is I got tired of dealing with Ubuntu being unable to be installed in my AMD Ryzen 2500U.
Yes, even with the latest version using the latest kernel, and my last attempt to install it was a few days ago in 2022.
Last time I mentioned this issue about AMD in this forum I was downvoted, but I don't care, I am writing now this comment from a nice laptop, and I'm back in Linux again, so I am happy with this decision.
My point is: yes, AMD market segmentation is better, and I wish them the best. But for my particular use case: Windows is not enough, and I require the machine to work in Linux, therefore Intel is a must.