Or to put it another way … as things stand today, a move from Intel to AMD would be a move back towards weaker security.
There is nothing fundamental about the difference between Intel and AMD. So if AMD wanted to help Purism to provide the same high level of security on AMD chips then AMD could be an option. As things stand today, Purism would have to do the work despite AMD.
This is not true. The IME has been partially disabled. There is a bet that what’s left is harmless, as it is small and doesn’t appear to connect to anything of import.
It is true that the AMD equivalent hasn’t been similarly gutted, but it’s non-gutted size is similar to the gutted IME, and it also doesn’t appear to connect to the network or otherwise do nefarious things.
The reason Purism is using Intel is momentum. When they started, ryzen wasn’t released; at this point, they’ve paid their engineers to analyze and neuter the IME. They could similarly audit the PSP firmware, but that’s a cost with little upside (people buying Purism products don’t care about performance or efficiency).
are Purism products really THAT inefficient ? i mean sure if you compare them to the multi-threaded AMD beasts then yes but otherwise they do the job quite fast (single-threaded-performance is still king for intel no ?)
People buying Purism products do care about performance and efficiency, but the weighting given to those factors, when considered along with cost and security, may differ from the mainstream.
Before worrying about the amount of code in the remaining homunculus modules, the first question would be: is it even possible to “disable” the homunculus CPU in an AMD system?
A combination of removing unneeded homunculus modules and use of the High Assurance Platform (HAP) mode makes the Intel homunculus CPU appear to be harmless, but that is assumed rather than being proven. Hence, in other words, does HAP mode even exist in an AMD system?
I could be wrong but I believe that the Intel homunculus code is obfuscated so that it cannot be audited by analyzing the machine code1, whereas the AMD homunculus code is vanilla ARM machine code and hence potentially could be laboriously audited. (Security mechanisms may however prevent changing the homunculus code if analyzing the machine code led to the discovery of nefarious functionality.)
1 unless the Huffman compression tables leak
If you aren’t stuck on thin-and-light, you can go with a desktop-replacement from system76 or R&J Tech (complete with desktop class CPUs). But that’s not the market Purism is targeting, so we’ll ignore that.
(As a side note, Intel’s just been dethroned for single-threaded performance on the desktop. Odds are they’ll come close to retaking it Q1 2021).
That said, we’re not talking desktop, we’re talking SFF and laptop (the librem mini uses a mobile class chip). Here thermal efficiency and energy efficiency dominate. Purism isn’t in as bad a position as they were 6 months ago (they skipped the 8th and 9th gen Intel parts, a 7th gen mobile Intel CPU gets crushed by zen2 mobile), but it’s still not great (the Librem 14 is still in preorder, so only sorta counts, the Librem 15 is still using a 4 year old CPU).
The 4500U has the same core count as the Intel part in the mini or 14, same TDP range (but measured power is generally lower, AMD “fudges” the numbers slightly less than Intel does), same single threaded performance (within margin of error anyway), and 10% better multithread performance. Against the librem mini (v1 or v2), it’s a slaughter, as the mini doesn’t have hyperthreading. (For what it’s worth, the Librem 15 loses in single threaded by 20% and in multithreaded by 70%, the 14 looks ok, the 15 is a bad deal unless you get it on a significant sale).
We’re digressing somewhat but I think that reflects timing in the upgrade cycle.
Real soon now … Librem 13 → Librem 14 (same physical dimensions but 1" extra in screen diagonal, and significantly upgraded hardware specs)
while the Librem 15 has not had that upgrade made available for pre-order. Is that upgrade going to occur for the Librem 15? I have no idea but I would assume that it has at least been discussed.
Right, I was over-generalizing. People truly in the RMS camp tend to stick to old 8bit machines or pre-2010 x86 systems. Purism’s main demographic is the people who want similar security but with at least some improved performance.
Short answer is “No”, it’s signed firmware, so short of getting a hold of the private signing key, you can’t change it. It’s also monolithic (the Intel stuff is similarly signed, and encrypted, but it’s in individual files, so you can delete ~90% of it).
That is a correct summation. The AMD ARM code appears to be “vanilla” ARM. It has been audited by two people/groups that have written at some length about it. Of course, we can only ever say it appears to be vanilla, because it could use undocumented opcodes to change its mode. (No, having the source code doesn’t help with that problem, you must eventually decide if you think the company involved is willing to spend the R&D budget it would take to hide nefarious functions).
The AMD PSP code is fairly similar to a decently written arduino application-specific-kernel (vs the intel one which uses a full Minix kernel internally), so tracing everything it’s responsible for was several weeks work. While one of the audits found it was only passably competent (include all of a standard libc library for a single function), they didn’t find anything problematic (no network access, so no remote code execution).
Aye, that’s quite fair, I suspect it’ll either get upgraded or discontinued.
That’s a bit different from what I was asking, although nevertheless useful and interesting info.
The question was whether HAP mode exists for AMD.
The attack against Intel ME has been two-fold: remove modules (which is possible because it is not monolithic) and disable it (HAP mode) after it has done what is “needed” to boot the main CPU.
I find it amusing that Intel(?) would call it High Assurance Platform mode i.e. a tacit admission that the Intel ME reduces the assurance of the system. The same for AMD of course.
I would like to see both vendors come out with a VHAP (Very High Assurance Platform) that simply doesn’t have a homunculus CPU. 
While network access by the homunculus is obviously a horrendous security issue, it can be managed (don’t even connect the built-in Intel ethernet to your LAN, and install a separate ethernet controller for actual use) … I would be far far more concerned about direct privileged access to basically everything in the system by the homunculus CPU.
You can easily come up with remote code execution scenarios (and much more besides).
Could you provide some links? We try to keep tabs on AMD status, and reading through the audits would be awesome.
That is the nub of it.
Getting AMD to the same (homunculus) level as Intel would take time and dollars.
In addition, I suppose there would be some board redesign costs.
Then there is the fragmentation of product (unless they went 100% AMD and ditched Intel entirely, excluding the phone of course).
Then there is the GPU issue.
Whatever the value proposition of AMD is, Purism would have to ask themselves … will we sell enough extra computers to recoup the cost of going AMD?
As I wrote before this topic was necrod, this has been discussed several times previously, and I always come away with the impression that … Intel/AMD is an unsatisfactory duopoly, AMD doesn’t present a compelling case for change (in the context of this niche market where security and privacy are of substantial importance), so we are really waiting for a disrupter that changes the game.
Unfortunately, I didn’t bother to bookmark the pages, but let me see what I can dig up from memory.
The main tool that made the analysis possible is PSPTool.
There was a presentation made on the topic about a year ago. You can find it here.
The mention of embedding one of the tiny C libraries for a single function was from a reddit post about 2 years ago (and was from a dissection of Zen1’s PSP code), but I can’t find it anymore.
The most recent one I found I heard about maybe 2 months ago, but dates to last December. They claim to have uploaded custom code to the PSP. @Ick posted a link to it back on Oct 24.
Hi, doesnt this post (https://cfp.osfc.io/osfc2020/featured/) mean that AMD will be blob free in future? The core boot project around Ronald Minnich is working on bringing open source firmware to AMD Zen.
Edit: the related post behind the link I am referring to is named “pure open source on an AMD Zen”.
no.
This talk will discuss project X, which is aimed at eXcising binary blobs from the x86 part of Zen CPUs. These parts start with fully functional memory, courtesy the ASP (which is a bit slow to get it done, but it gets it done). Getting memory working is just about the hardest part of bringing up a platform. Since the x86 is released from reset with memory working, things are easier.
the key phrase is the x86 part of Zen CPUs. The PSP is an ARM core, and on Zen CPUs, it performs RAM init before the x86 part comes out of reset. So you’re still left with RAM training/init being perfomed by a blob, that blob just happens to run on another (ARM) CPU.
the more you know right ?
As far as I’m concerned, the performance difference between AMD and Intel simply isn’t enough to worry about when we are comparing U-series processors for laptops.
Comparing Intel’s best mobile processor (Core i7-1185G7) to AMD’s best mobile processor (Ryzen 9 4900U).1,2, it is basically a toss-up which is better. Intel wins in terms of graphics, single-core performance (because of higher single-core clock speed), and AI. AMD wins in terms of energy efficiency (i.e., battery life) and multi-core performance (because it has 8 cores whereas the i7-1185G7 only has 4 cores).
Most people don’t run software that can use 8 cores, so the i7-1185G7 will probably give them better performance. For some people, battery life is extremely important, so Ryzen 9 4900U will be better. Even for people who care about multi-core performance, such as people doing video rendering, the choice is not clear. The i7-1185G7 has a better GPU (Intel Xe Graphics G7), which helps when doing video editing and most video rendering software can use the GPGPU functions. The i7-1185G7 supports up to 64GB RAM, whereas the Ryzen 9 4900U only supports up to 32GB RAM, which may be a factor when doing video rendering.
Intel is better than AMD in terms of its support for FOSS. Intel has contributed 7.65% of the code in the Linux kernel, whereas AMD has contributed 1.90%. Intel develops the graphics driver for its CPUs in mainline Linux, whereas AMD contributes to the FOSS driver for Radeon GPUs, but mainly releases info and lets the community develop it. Maybe this difference is simply because Intel was a much richer company and could afford to spend more money on supporting Linux.
On the other hand, Intel has a long history of monopolistic practices, which people may not want to support. In 2009, the EU fined Intel $1.45 billion for violating European anti-trust laws.
Some people may also want to boycott Intel, because it has invested $35 billion in Israel, and has operated fabs at Kiryat Gat since 1999. Intel currently plans to invest $5 billion in upgrading its Kiryat Gat fab and is considering investing even more in the future.
Al-Awda, the Palestinian Right to Return Coalition, has called on Intel to close its plants in Kiryat Gat, which was the site of the former Palestinian villages Iraq al-Manshiya and Faluja, that were ethnically cleansed by the Israelis in 1948-49.
At this point, I’m not sure that Intel still has a monopoly position that it can abuse. However, I do find the BDS argument against Intel to be compelling.
Please please please, if anyone wants to argue this, use “Reply as linked topic” into Round Table. This is an obvious red flag subject that could lead to an argument as long as anything in this forum with everyone having an entrenched position and noone ever ever going to change position , but will totally sidetrack from the more objective and technical aspects of whether Purism can and should develop AMD laptops, in addition to or instead of Intel laptops.
So, even with a dedicated AMD GPU using the open source driver, that still requires non-free blobs somewhere?
If I’m buying a new laptop, it needs to be a powerful and sturdy machine so I’d need higher-end graphics capabilities. Else, I’m content with less expensive old, used devices.
All three major GPU vendors require non-free code running on the GPU itself (remember, a GPU is just a hyper-specialized CPU). Intel is the only one which embeds a copy of that non-free firmware in the GPU itself, which means you don’t have to upload that firmware to the GPU at system startup. Of course, if you go with the embedded version you miss out on security and performance “bug fixes”. (It’s similar to CPU microcode, where the CPU functions without it, but choosing to skip the microcode updates has security and performance implications, positive and negative).
To be clear, neither the integrated nor the discreet AMD gpus require running non-free blobs on the CPU, they “just” require uploading some blobs to the GPU’s volatile memory at startup.
Also to be clear, the integrated (and discreet) Intel GPUs require non-free blobs, they’re just embedded in the GPU package itself.
So, under the rules that Purism is trying to comply with, Intel is OK and AMD is not OK?
That’s an interesting question… Neither Intel nor AMD CPUs comply with the FSF RYF requirements. But nearly no equipment does, so the RYF requirements for system integrators (SIs) has an exception for devices which contain non-free firmware which the end user can ignore (the actual wording is a bit vague, but that seems to be the meaning). This was intended for the firmware on components like hard drives, where the exposed interface can be used via free software, but the internal system is not documented.
Of course, that exception was included for components other than the CPU, it isn’t supposed to apply when the non-free code is executed by the CPU. In that case, neither Intel nor AMD CPUs (or APUs/iGPUs) are OK. If the FSF clarifies their position that the included microcode (which executes on the CPU) is OK, then both are fine (assuming the IME/PSP is neutralized, that’s a separate issue).
Of course, that does leave AMD with a minor issue that the preloaded microcode for their APUs can only handle VESA mode, and the end user must not be expected to deal with the non-free firmware. Essentially, the end user must be able to take a free-software-only OS, install it on the computer, and have it function. It’s a minor issue because an SI could embed the needed firmware in an SPI flash chip, on the board, thereby letting it survive drive wipes. That is essentially the position the Intel iGPUs are in.
I can’t speak to Intel dGPUs, as they aren’t really available yet. AMD’s dGPUs are in the same position as their APUs, and a SI could enable them in a similar fashion.