For everybody wondering: PSP stands for Platform Security Processor, a secure enclave in the processor and AMD's version of the Intel Management Engine.
Quoting from Libreboot:
As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI/PCIe peripherals installed on the system.
Well, that’s not true. Sure, connect it over PCIE and all bets are off, but connect it over USB and you should be fine. If you’re being super careful buy a Bluetooth 3G module.
Yeah, but apparently the PS4 was originally hacked through bugs in the IOMMU. I basically don't trust an IOMMU that I don't have the source to and that hasn't been formally verified (so all of them).
One thing that kind of bothers me is that I keep seeing people justify this decision by mentioning that AMD may be using third party source code which they do not have the license to release.
My issue with that is that I don’t see how it prevents AMD from releasing a super stripped down (essentially disabled), but still closed source version of the firmware. There may very well be a valid justification for not doing so - I just don’t know.
An even better approach would be to allow the system to run without the firmware at all. If I remember correctly, some Intel machines will run for 30 minutes without the firmware, but will shut down after the time elapses. If true, that at least proves that it’s not essential for system operation.
In the case of Intel, surely they could have disabled this 30 minute timer on the consumer CPUs (just like how they disable ECC support).
I think the justification is economic. They don't remove it because it's not clear that there is a market for not having ME. The reason (I think) they remove ECC support is that people are willing to pay extra for it, so they remove it so you are forced to pay extra. If they removed ME in consumer CPUs, they wouldn't sell any more consumer CPUs and their enterprise management system wouldn't be any more popular.
There are also some additional problems. Intel ME is used by Linux quite heavily (rather than talking directly to the embedded controller) which means that certain things can become quite flaky. I have Coreboot on my X220 with me_cleaner, and my machine seems to freeze randomly (it's definitely not the 30-minute timer, I just think it's IO being deadlocked for some reason). While your machine may appear to work without ME, there are almost certainly features that won't work.
Here's the kernel documentation about the Intel MEI driver (Management Engine Interface) which describes the /dev/mei node that allows you to manage AMT and other things on your local machine[1]. And HECI[2] also goes through Intel ME. So anything that uses either of those things requires Intel ME, and Linux provides support for both.
I also believe that I've read somewhere that the reason you need to use tools that talk directly to the EC to modify things like battery levels with coreboot (as opposed to the "standard" tools used on stock machines) is because of the lack of those interfaces for Linux.
I may be mistaken about the latter, but it is definitely true there are useful things that Linux does provide support for (and might use internally, I'm not sure).
The economic pressure to fix this, if it happens, will come from the enterprise side: Some large, cyber-security-conscious (that should be all of them, but alas) customer moving towards a policy that bans unauditable MEs with DMA.
But those same enterprises like being able to manage their employee's laptops using Intel's management system (which is why Intel ME has its backdoor features).
Hmm, I admit this is an anecodate rather than a statistic, buut,
100% of large corporations that I know of which have an opinion on these things (all one them) laugh Intel's AMT and are glad they have done what they can to disable the firmware (they can do more than you or I can do).
Giant corporations are perfectly capable of controlling their own laptops.
It's quite clear that people are buying Intel's management systems, which use Intel AMT and Intel ME. So you're right that it's just an anecdote, because it doesn't explain why people are buying those products.
Yes, of course. There are plenty of legitimate uses of a management platform. But they also like (or should like...) to be sure they're the only ones who can do so.
The interesting question is whether someone could reverse-engineer this and publish everything they find freely on the Internet? It surely can't be easy, but just imagine someone would do that, maybe even be so irresponsible as to publish exploits! That could become a nightmare for AMD and Intel!
> It surely can't be easy, but just imagine someone would do that, maybe even be so irresponsible as to publish exploits! That could become a nightmare for AMD and Intel!
Something similar happened just a few months ago: It all started with this article:
What finally happened: A set of firmware updates was released by Intel to the hardware vendors. These were installed by careful admins and users. After this the story mostly got forgotten. So the bug source was indeed probably a nightmare for Intel - but the public did not really care for it except for some nerds.
It's quite easy to build CPUs which have features disabled at manufacturing by one-time fuses, or laser fuses. Also there is undoubtedly a (maybe small) bin of CPUs which have failed QA only because of a fault in the management engine.
Back in the days of the 486SX/DX, it was far more normal to sell processors with features disabled for less money. Why don't AMD and Intel want to monetise their management features?
> Why don't AMD and Intel want to monetise their management features?
They do, most machines don't have remote management firmware and chipset features installed.
As for why the ME is present on all hardware - it would be a shame if your consumer CPU couldn't securely decode super-4K-full-ultra-HD videos, right?
Besides DRM, I think the ME is also used for SGX.
Intel(R) Software Guard Extensions (Intel(R) SGX) is an Intel technology for application developers seeking to protect select code and data from disclosure or modification.
Maybe Intel wants to create some "ecosystem" of software utilizing SGX (because vendor lock in) and for that they want as large hardware base as possible. That's just a guess, I haven't read Intel docs and IDK if any off-the-shelf SGX software exists yet, but I have seen similar ideas in some AMD PSP PDFs.
edit:
FWIW, Intel Wikivertisement on SGX:
The introduction of SGX has a large impact on the security industry. It shifts how security is being achieved and lowers the attack surface area of projects. One example of SGX used in security was a demo application from wolfSSL using it for cryptography algorithms. One example of a secure service built using SGX is Fortanix's key management service. This entire cloud based service is built using SGX servers and designed to provide privacy from cloud provider. An additional example is Numecent using SGX to protect the DRM that is used to authorize application execution with their Cloudpaging application delivery products.
AFAIU SGX has nothing to do with the ME. It's entirely in the CPU and MMU. SGX is more like ARM's TrustZone, except it can be utilized by multiple, independent pieces of unprivileged code. SGX is pretty slick. The only real problem is that 1) Intel has done a horrible job of educating developers, 2) Intel's PKI scheme for remotely verifying authenticity of an enclave (e.g. for DRM schemes) requires huge on-going license payments to Intel, and 3) they don't seem keen on rolling it out across their entire processor line-up. All three cases have been and will continue to be serious impediments to uptake because of the confusion they create. Those impediments are likely to keep SGX niche and underutilized.
Thanks, it seems you are right. I thought that the ME plays some role in SGX setup but I can't find a single source for that now. Apparently it's all done with special instructions implemented in microcode.
Intel seems to gate their management features through the chipsets instead, with vPro as the primary user-accessible interface being limited to business lines.
> I think the justification is economic. They don't remove it because it's not clear that there is a market for not having ME.
Yes, especially when you stand to lose billions of dollars in contracts with the DoD by removing the remotely exploitable ME from processors. It's probably that kind of economic loss.
>There may very well be a valid justification for not doing so - I just don’t know.
Is there even any question at this point? The NSA doesn't want them stripping out their backdoors. Remember when Intel 'accidentally' managed to screw up a simple string comparison in a way that would conveniently allow remote access without password?
No, because the firmware is in some part written in a ROM inside the CPU (for security reason, at least the part that has to verify and load the rest of the firmware from the external flash memory), so there is no way to replace it or even disable it (if there is a way, you could see it as a potential backdoor, and also an attacker could disable the firmware and bypass secure boot for example)
I think this comment on the reddit thread is a pretty accurate take on the whole thing:
"Not that anyone could have seriously expected that.
If AMD makes a business decision to possibly open source the PSP now or in the near future, the first results will be visible 2-3 years later, at best. However, it is VERY likely that there are legal barriers, such as 3rd party code. Maybe they are using a 3rd party RTOS that they cannot publish the sources of? Or maybe some DRM part of the PSP firmware can't be published?
What I'd personally like to see is a minimal PSP implementation (without any noticeable features) that's Open Source, with reproducible build process and a binary of that signed by AMD."
> What I'd personally like to see is a minimal PSP implementation (without any noticeable features) that's Open Source, with reproducible build process and a binary of that signed by AMD.
There are 3rd party efforts to produce something similar on Intel platforms:
The sad thing is, we can be sure, that AMD is aware of the topic at the C-level and doesn't seem to act in the interest of the customer anyway. Just remember the Reddit AMA earlier this year: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...
I'm always mildly surprised to find people posturing that having closed source modules in the CPU is completely intolerable while basically all modern hardware is closed source. Even if they release the source code for the PSP they won't release the verilog of the underlying IP to see how it's implemented. And you'd still run a closed source CPU, with a closed source GPU and a closed source USB controller and a closed source PCI controller etc etc...
How many of the people complaining about the lack of PSP source code are willingly running a closed source GPU driver? How many of them are running Windows, Mac OS or some other closed source operating system?
It reminds me of when people were blowing a fuse over the linux kernel's use of Intel's built-in PRNG.
I'm all for open hardware design but focusing on these particular modules is a bit counterproductive I think, if tomorrow AMD or Intel were to release CPUs without this particular "feature" the surface of attack would not shrink massively.
Hardware is open or it's not. Nowadays it's overwhelmingly not open, so you have to blindly trust AMD, Intel and the variour ARM SoC vendors not to fuck you over[1] and having the PSP source code wouldn't change much about that.
You can get a machine to run reasonably well without relying on closed source graphics drivers. If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. If a driver is compromised, there will be signs of abnormal behaviour (you can inspect what software on your machine is doing at runtime).
With AMD's PSP or Intel's ME, there are no such limitations in how bad things can get. These things could take all the data you have in memory, connect to some shady network location and dump all the data. All the while there is no trace of that activity in your OS, because of none of this nonsense lives in your OS.
> If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network.
How can you be confident of this when your GPU can DMA into anything?
at least for Intel processors only the more expensive ones support IOMMU (Intel VT-d). On the other hand for modern AMD processors this feature seems to be commonly supported.
of course if your GPU can DMA anything, then all bets are off. But provided you are in control of all pathways connecting to your GPU, and can bitsniff the traffic, then you can verify that it isn't doing anything that your open-source driver doesn't want it to.
Sure, if you do do that on every piece of hardware. Which means your drivers are all either sandboxed or formally verified, as are the parts of the kernel that touch them, and the parts that touch them...
I guess my point is that as long as the hardware itself is closed source you have to trust the vendor anyway. Suppose the PSP source code was open sourced, how can you be sure it's actually what's being run by the CPU? How can you know certain instructions aren't backdoored somehow?
It makes it a bit more difficult to implement such backdoors of course, but it's still perfectly doable.
Again, I'm happy that people value their privacy and campaign for more open source but it seems a bit myopic to put all our attention on this tiny part of the problem. The risk is that if tomorrow AMD decides to actually open source the PSP many people will think that we won and the battle is over when we've just removed one of thousands of possible attack vectors.
> as long as the hardware itself is closed source you have to trust the vendor anyway
Because it's an ongoing effort. Years ago people were running GNU software on proprietary kernels/operating systems.
You can't get to fully free and open hardware in one step. Firmware is the next battlefield, and its an area that hardware manufacturers have been winning. The firmware on a modern machine is orders of magnitude larger than it was 10 years ago, while provided essentially the same features. More and more closed source code is running on your machine.
If we don't push back sooner or later your linux install will only be running in a virtualized environment provided by the proprietary OS running in "firmware"
Analysts working on the Intel ME can test if its active by testing line voltages around he mainboard. Someone did manage to hard disable it, and it could be proven in how voltages dropped at various points on the motherboard. If all else fails it is still a physical piece of hardware.
That's good, but then shouldn't we petition to have a way to physically disable these modules instead of begging for a source code that won't get us anywhere closer to a trusted computing environment? It's a lot easier to validate that something is not running than it is to validate that it's running correctly.
Intentional hardware backdoors are hopefully small and made by somewhat competent people. Hardware vendors already can't be trusted with writing code that does something useful there is no need to have any additional attack surface in code that provides almost no valuable functionality.
Even if hardware is not open, hardware can be isolated. Then provided you are in control of the communication between the isolated hardware, you can be more certain that you are in control. Security through isolation doesn't require perfect security of the closed components. The problem with the management engine is that it can't be isolated.
As the trend is to integrate more and more IPs into System-on-Chips hardware isolation is not really a given nowadays. You still have external memory I suppose, but you can do a lot just messing with the caches and the rest of the pipeline especially when we have more "high level" instruction sets dealing with AES and other crypto algorithms natively.
Also I don't really see how having access to the PSP source code would factor into that. As long as you can't prove that the management engine is really running that code unmodified and there's no hardware backdoor to change its behaviour it won't really get you anywhere.
Obviously if the hardware is all integrated together, then you can't do isolation as I described. However, in your parent comment you used the example of a GPU, which is something that can perfectly be fined be isolated, and provided you can write an open-source driver and can bitsniff all the data coming in and out of your untrusted GPU, then you can be reasonably sure it is not for instance sending your screen data to your network controller.
Just for your information to help you do further research: AMD seems not to use the brand name "AMD PSP" anymore. Instead some years ago they began to use the name "AMD Secure Processor". Nevertheless it is just the same: Read the small footnore at http://www.amd.com/en-gb/innovations/software-technologies/s... which begins with 'AMD Secure Processor (formerly “Platform Security Processor” or “PSP”)'.
It seems like many in this thread get stuck on the idea that Intel "already has the ME, so what's the point?"
The point is, I prefer Intel due to performance reasons. But I would have changed over to AMD permanently if they open sourced the PSP code, or if they removed the PSP entirely. That would have been their one competitive advantage, and now they've shat all over it, and lost many potential customers.
> and now they've shat all over it, and lost many potential customers.
Yes, I'm sure people are turning away in droves from the most competitive AMD processor in a decade because they won't open source their version of ME.
Not in "droves", you're right. BUT, there is a very small, privacy-conscious, vocal minority that does not want an obvious backdoor hiding in their CPU. I am one member of that minority, and I won't be purchasing from AMD again until they right this situation.
It's similar to the gaming enthusiast market, though a lot smaller. You can market to that small segment for a big win, because gamers will shell out for the newest GPUs, talk up the hardware online, which leads to increased sales. If AMD would see the benefit of working with this privacy-conscious segment of the market, I believe they would also see, not a major, but also not an insignificant uptick in sales.
Even on raw performance AMD is pretty close to comparable (i.e. I ran my top of the line intel i7 machine along side my top of the line AMD machine and there was no noticeable differences).
tl;dr: the PSP is a full computer that lives between the instructions that get sent to your CPU and what your CPU actually executes. It's obviously a huge security problem, because if a backdoor in the PSP gets exploited, you cannot trust your computer in any way, and there is no way for you to verify whether it is being exploited or not. AMD said they might open source it, but even that wouldn't do much to establish trust.
right, and releasing the source code is giving a map to criminals to allow them to hack it.
The "no security through obscurity" theory is not entirely true in the real world.
When you push up the cost (money and skill) of a hack then hackers will attack weaker components and so the likelihood of a hack is smaller.
This code is highly secure and would require an enormous amount of specialist knowledge, equipment, and time to extract, analyze and exploit.
The effort involved rules out rational profit motivated individuals because the costs are too high and there are plentiful opportunities for lower cost exploits.
No company releases the source for their DRM code except to legitimately interested parties in controlled circumstances and that is the correct policy from a security perspective.
We don't need the fucking code, we need it to just be OPTIONAL. Just an option to FULLY DISABLE IT. Screw everyone who said "open source it" instead of "disable it" >_<
If might have been if AMD were opening up and Intel weren't.
EDIT to expand a bit since some people seem to be missing the point: hypothetically, GP might have preferred Intel on narrow technical criteria, but have been willing to override that preference for the sake of transparency. No transparency difference, no reason to override.
Well in this line of thought at least now there's a chance competition will set either/both on that path.
Fwiw I'm not ready to use open-ish ARM/POWER exclusively, but AMD/Intel'll have to contend with that soon(tm)
[Answer to parents EDIT]
I'd argue the effective technical difference set between AMD & Intel is growing ever narrower, and aside from brand fidelity there is very little reason for a consumer to have non-moral preferences to one or the other manufacturer.
I don't know the plans with TALOS II, but those who are interested in what happened to the original Talos Secure Workstation crowdfunding might be interested in the following article, which I think anybody, who is interested in how an alternative could look like, should read:
Sorry, I'm confused by your response. I was saying that if AMD took a different approach from Intel, it would have been a differentiating attribute and I would have been swayed in that direction.
ARM has TrustZone. OpenPOWER or RISC-V are the only real options at the moment, and both of them are prohibitively expensive to get hardware for and basically require using a softcore in an FPGA.
Are there examples of non-TrustZone ARM SoCs? I'm not aware of any, which would make it a moot point about whether a theoretical vendor could make the decision to not includ eit.
The hikey and hikey960 devboards let you build your own code to run in the trustzone - eg the boot chain isn't signed and secure. The trustzone and uefi implemention these boards use is also fully open source.
Maybe we should start with stating that the core of TZ is an execution mode of the ARM CPU privileged above the normal kernel mode, not a separate core running some obscure code. TZ can run any suitable hypervisor or just be left unused. It's nothing like the ME/PSP.
Still, some boards/devices may lock it down, for example by code signing.
I think it gets obfuscated due to the fact that about the only public information that AMD provides on the PSP is that it uses ARM Trustzone technology.
Most likely the best you'll get is either a fully usable TrustZone SoC (so you can have your bootloader or linux do what you want) or there are SKUs of SoC where the ROM locks the various TZ registers into certain configurations which is meant to disable any runtime usage of the TZ by higher level SW e.g. bootloader or OS.
If you are making something with the SoC.. it's probably safer to buy the locked down version of the SoC than to mess about with TZ or to leave it open.
An ARM CPU is hardly comparable to an Intel/AMD CPU. And I don't mean in terms of performance.
The CPUs from Intel/AMD are much more than a simple CPU, they are a complete system on a chip with a lot of more features that go beyond processing power for your system. On the other hand, an ARM CPU is just a simple CPU.
If you want to make comparisons, a more correct one would be between the Intel/AMD CPUs and a Snapdragon processor.
ARM chips have been full SoCs for far longer than x86 chips have been. It took a while for Intel and AMD to integrate the memory controllers and PCI root complex onto the CPU rather than in the northbridge.
AKAIK, only the Versatile/RealView style boards that an SoC manufacturer would get directly from ARM come with bare ARM chips. Anything other than that is an SoC.
My point is that an Intel/AMD product is a complete solution while an ARM product is just the very basic implementation of a CPU.
ARM doesn't mandate on anything related to the SoC except for the CPU, everything else related to PCI buses, memories, physical implementation, chipsets, etc, is up to the SoC developer to decide and implement.
And event then you have to trust the closed source synthesis tools on top of the FPGA itself... Of course it would be harder to backdoor but it's probably doable, especially if it targets those particular designs specifically.
There's simply no way to get a completely trusted computer stack nowadays, short of assembling it by hand using discrete electronics. It won't run very fast though...
I guess an alternative would be to crowdfund the production of an open source CPU then take a few samples and send them to people with an electron microscope and a lot of patience to make sure that the silicon really matches the design and wasn't tempered with in the fab.
> Curious what giants like Google do in these cases. I assume in their vast farms of servers there are post-2006 intel and/or post-2013 amd chips.
As far as I know Google mostly uses Xeons in their server farms, but also some POWER9 servers (for example cf. https://cloudplatform.googleblog.com/2016/10/introducing-Zai...) - many people say this is "some kind of Google's insurance against Intel/x86":
> Do they get a special deal to look under the hood?
It is well-known that the largest buyers of Xeons (plausible names are Google, Microsoft, Amazon, Facebook, Alibaba and some others) have access to special versions of Xeons that have special features enabled that are disabled in the versions sold to the general public. One article giving hints into this direction is
One such feature that is talked about is having access to an FPGA (why did Intel buy Altera again) and it is well-known that Microsoft uses FPGAs for Bing:
Never heard about PSP before. Looks like another corner of the computer world in total lockdown and relies on security through obscurity. Not gonna work forever but keeps all but the talented people out. Problem is there are many talented people out there.
It's safe to assume hardware and software is completely and totally backdoored. It's done with NSLs and co-operation of companies or compromising employees, projects, standards and other tricks which are child's play for most government agencies.
That makes the idea of using technology to gain some sort of privacy from state level actors with infinite resources and man power to thwart you a total nonstarter that can at best deliver a false sense of security and at worst more serious consequences for those who may need it.
The bottom line is established power is paranoid and wants to monitor all communication whatever they may proclaim publicly and it appears from hind sight and what we now know they have always done it.
What can we do about this? This is completely unacceptable! Note, I'm not referring to the source code, I could care less, I'm referring to removing this obvious breach of privacy that will be used by governments.
> That, however, limits you to POWER9 and Risc-V computers.
Where can I buy a RISC-V computer?
I.e. not only some microcontroller board "which is just a much faster Arduino", but a board that has the usual capabilities that one expects from a computer such as GPU, ethernet, USB jacks, audio in/out (either audio jack or via HDMI), possibility to connect a SSD, and perhaps an SD card slot and RAM slots to increase the RAM if one desires.
It allows for a richer bootstrap than the x86 BIOS/UEFI, including checking signatures for the boot device.
This helps mitigate attacks like persistent rootkits that alter the OS to mask the presence of malware.
However, as a supervisor processor, the PSP is also a risk itself. If a well funded state setup a shipping interdiction on import or export, they could alter the PSP to insert their malware and we wouldn't be able to audit it.
This is a gift from all of those mobile SoCs that might've gotten signed bootloaders initially just to protect the subsidy. Part of the overall "death of the general purpose computer" (see Doctorow for more).
How can you protect against this attack vector? Could you dump & hash the PSP firmware, then compare with other non-imported hashes to check for tampering?
I doubt it -- if it was designed well, the PSP won't reveal anything about itself to the x86 processor and won't have any off-chip memory. I think the state-of-the-art is the Apple Secure Enclave Processor, which is probably old enough to have inspired some of the PSP design.
Maybe a side-channel attack could help reveal the PSP firmware or other vulnerable design elements. But I'm pretty pessimistic -- the number of organizations/people capable of investing in the time and equipment necessary to do this is low.
Doing the comparison with code running on the potentially compromised system does not tell you much. Doing it another way is expensive for large scale (involves pulling chips and seeing what's in them).
It runs in god mode with access to anything and everything, and is completely hidden from even system mode software. With access to peripherals it can access the network and take remote commands, exfiltrate data, etc.
If you've ever used a server they often have a nice feature where you send an authenticated command to them on a certain port and get it to shutoff, turn on, reboot, whatever. This is run from the PSP on AMD processors.
Or maybe it has a remote backdoor put there by the NSA (or maybe just escrowed command and control keys) and ANY AMD device connected to the Internet can be controlled remotely by them at will. We have no way of knowing.
Or if TLAs don't worry you, then maybe the code running on it has a 0-day vulnerability and every server out there is vulnerable to remote code execution + the ultimate privilege escalation and we don't know about.
Or if that doesn't worry you, then maybe it'd at least be nice to be able to program it yourself and add new features, bug fixes, etc.
Those are all good reasons for requesting open source PSP code.
I don't mean to downplay this, but intel's doing it too with their management engine.
Don't bash AMD for this specifically, at least now we-consumers have a realistic choice as to the purveyor of backdoors. It's... something?
AMD has traditionally been a more consumer-friendly vendor and there was some hope that they might differentiate themselves from intel in this way, giving people concerned about this at least one major vendor to source their parts from. Alas, that is not the case.
Raptor Engineering makes/may eventually make(?) the "Talos Secure Workstation" based on POWER8. They claim "schematics and libre (fully open and auditable) firmware also are included." Don't know; don't own one. A mere $5,300 gets/might get you an 8 core workstation.
IBM makes POWER CPUs and you may assume that -- unless they've disclosed something -- no one other than IBM and the NSA really know if there are any unauditable "support" processors on the die. Beyond that the Raptor site mentions that there are still some bits you don't get to know about their system: "several pages will be redacted on the public schematic due to mandatory NDAs with a few of our support silicon vendors."
Everything else is SOC/MCU stuff; nothing that approaches the capabilities of these Intel and AMD CPUs. You could hold out on older pre-ME/PSP systems until RISC-V goes through enough evolution and market success to achieve parity with then-contemporary devices, sometime around 2035 I'd guess...
Answer to your question is, in most cases, simply no.
>until RISC-V goes through enough evolution and market success to achieve parity with then-contemporary devices, sometime around 2035 I'd guess...
RISC-V just refers to the ISA, right ? An implementation by a vendor may still have ME/PSP like stuff, just like the x86 ISA has nothing to do with ME/PSP.
Sure. One can imagine a 64-bit 24 core RISC-V CPU with 60 billion transistors, all backdoored by some management processor. Perhaps by then the management CPU will be an x86 core running Linux.
Open sourcing the PSP code (or probably any other firmware) may not help protect you (or anyone) in terms of security or privacy.
Here is where open source is different from free software, and this is why free software is better than open source.
Say for example, ddwrt, a very popular firmware used in several routers. Or simply saying, Linux (kernel) + busybox, a very popular combination of some open source codes used in several embedded systems: They are simply open source when they run on those systems, not free software. You can't replace their code with some (custom) versions most of the time.
All you get is the source code, you may not be allowed to run custom version. You may not even be able to confirm if the code they gave is the code that is actually being run on those devices.
As always said, that is enough to fit to the terms of "open source". And yes, just another reason why free software is (almost always) better than open source.
Looks like high performance comes at a security cost. It's a good thing projects like RISC V and certain boards like the TALOS exist or else it'd be a hell of a time. Has anyone here tried some tech from SiFive? They appear to have RISC V boards for sale.
Excuse my French but what a fucking surprise. Who ever thought they would? That's right, I did.
Hence I'm a bit pissed off right now. But even though I was dumb enough to believe, at least I was smart enough to wait for it, and did not waste my money.
I wonder, is there some way mathematically that software could be written that's still secure (or unfeasibly difficult to crack) when running on a system with AMD's PSP or Intel's IME?
Every Intel CPU since 2006 and every AMD CPU since 2013 has this stuff. If you care about this possible solutions are:
buy pre-2006/pre-2013 hardware;
go through some procedure to remove the ME[1];
forget x86 entirely (ARM?)
Yes, all modern AMD processors have this. But Intel processors have an equivalent ""feature"", called the Intel Management Engine (ME). So take you pick really.
Is there any reason why people were (seemingly) expecting this, or was it just an idea that gained momentum that AMD never actually suggested or considered?
It was brought up in a subreddit thread and an AMD PR replied to it saying they'll look into it or something a long the line.
The thread was basically everybody saying they would buy AMD if they release the code because they'll be the only friend CPU towards the open source community.
This was actually awhile ago, I was the reading the thread too.
The number of people on this planet with the singular knowledge to build a modern processor, from scratch, I would estimate is well under 1,000. The number with the knowledge and the resources to do so is even lower.
Telling someone if they don't like their processor choices to "build their own" is like telling someone to build their own ISP/Telco service if they're not happy with the sole Comcast offering in their area.
> The number of people on this planet with the singular knowledge to build a modern processor, from scratch, I would estimate is well under 1,000
I am pretty sure that most EE/CE students at some point or another implement a basic processor on a fpga. That being said, I am not sure how many of them would be able to build a "modern" one.
Yeah the number people who can, by themselves or with a small team, build a modern processor that's half as fast or half as efficient as something AMD put out 10 years ago is so small it's actually probably a negative number. Fabs are really, really, really really really expensive and processors are really hard to design.
Quoting from Libreboot:
As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI/PCIe peripherals installed on the system.