Slashdot Mirror
AMD Has No Plans To Release PSP Code (twitch.tv)
AMD has faced calls from Edward Snowden, Libreboot and the Reddit community to release the source code to the AMD Secure Processor (PSP), a network-capable co-processor which some believe has the capacity to act as a backdoor. But despite some signs earlier that it might consider opening the PSP code at some point, the chip-maker has now confirmed that there hasn't been a change of heart yet. "We have no plans on releasing it to the public," the company executives said in a tech talk (video).
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.
AMD is no doubt being bitten on the sack for using third parts code and we again see why everything should be open sources.
Closed source, out of band co-processors on every motherboard currently in production with no oversight or accountability? I'm surprised we don't have a third party stepping up here, like Samsung or Qualcomm, ready to take a crack at the CPU market with this kind of an opportunity.
Enough with this secure backdoor bullshit. I'm getting to the point where I'm making small preparations to remove myself from any digital communication or data systems whatsoever.
How long are we going to continue to buy products that are actively working against us? I realize that one has to use technology to survive in today's world, but that doesn't mean one has to use it for anything more than the bare minimum. No cell phone, no laptop, no cameras in my house, no always on microphone "assistants". OTA TV and a desktop computer running Linux that's only booted up for survival needs or basic web surfing. Running a very old, pre-PSP AMD processor or possibly a pre AMT Intel. That's where it's heading. Nothing can be trusted.
But DS code is allowed
Huh? What's wrong with you, are you an icky weirdo or something? I bet you don't have a facebook either or watch television at least 20 hours per week. That's sooooo creepy.
Proof that it is a backdoor and that the crucial support of their business is a contract from the plutocracy, meaning that if they stop playing ball, they go out of business.
Another chip manufacturer that cannot be used for trustworthy IT infrastructure. Who's next on the chopping block?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
... someone cuts it open and we all see some genuis braindead decision made by a fuckwit that either:
allows a third party access 'accidentally'
blows the whole system up by explosing a trivial exploit that's massive
uses some GPL'ed code that should have made it open in the first place.
There is no security by obscurity by using hardware everyone has (and can cut open)
there was a crowd funding for risc-v cpu, 100% open source cpu (a first) but barely 200 peoples (including me) contributed. They seemed to have the skill tech skill (other ASIC done in the past) but not the PR to reach peoples. Although it seem peoples (at least 99.9% of them) just don't give a s*** about backdoor or not.
No Plans to buy their backdoored hardware then.
I think that says all.
The last strippable Intel hardware ME without signed GPU is the 1155/2011 v3 core stuff, right?
If I need newer GPUs that may become my fallback platform, with AM3 primary, followed by AM3+ as a fallback. Although AFAIK 3+ and FM2 had PSPs just software/hardware disabled?
It really is time to crowdsource all three of: RISC-V, the open source Hitachi SH J2/4/6 chips, and SPARC chip derivatives, each with support for a common CPU socket and an open source chipset initialization/management engine. Maybe emulating/implementing IA32/UEFI for PC compatible peripheral board bringup, then start unveiling open hardware versions of GPUs and other hardware from there.
But *NOW* is the time for the techie community to band together, get off our collective asses, and *GET THIS DONE*. I mean if Bitcoin was able to get ASICs within ~3 years, getting ASIC CPU/Motherboard chipsets done within 3 years should be within our community's capabilities. And now is the time to do it, at least as fast as industry is capable of developing a design. Chip Gracey of Propeller/STAMP fame managed to get 180NM stencils done for a few hundred grand. Even if we had to step from P3-P4 era technology and work up to a smaller and more current process to reach performance parity, it would be worth it for a libre chip design. And gives us an opportunity to do things that don't make 'mass market' sense yet. Like producing a dual or quad core 128 bit RISC-V variant, porting linux to it, and then not panicking in another 5 or 10 years when the 52-53 bit addressing limitation of x86_64 comes back to bite everyone in the ass, just like the '2, maybe 3 gig' application space did for IA32.
Anyway, fuck AMD. If someone, maybe vivante, qualcomm (oh the irony!), or broadcom was to produce a discrete version of their GPU IP without requiring firmware signing, I'd be all over that like stink on shit. If they don't, then the community really needs to start work on crowdfunding that, along with a cpu/motherboard platform, so we can free ourselves before it is too late.
Or maybe it is already too late, since despite this discussion being made 5-10 years ago when Intel starting locking shit down, nothing has REALLY been done towards taping out an alternative :(
Go ahead, try to keep this stuff secret. There will be leakers and if you will be embarrassed by the leaks, it's better to come clean now than to be the center of market turmoil when the vulnerabilities are disclosed.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Just watch your network traffic, right? And those with really fancy tools can measure all the pin outs?
“He’s not deformed, he’s just drunk!”
I had not idea that AMD was behind the Sony PlayStation Portable (PSP).
considering its made up of a solid 90% of the people who might purposefully seek out an AMD cpu at this point, its a legit bloc. Kinda like saying politicians should ignore old people just because they all live in retirement homes.
This is the same topic as for the Intel Management Engine, for example Is the Intel Management Engine a backdoor?
Period.
Will $CURRENT_YEAR be the year of the Linux Desktop?
With the Intel AMT Platform, it is possible to render it "inert" such that yes its there, yes its running, but it won't accept any connections from the outside world. There is a Linux utility for checking if AMT is working or not. But Linux can't turn it on.
The problem is if you have Windows installed, Windows CAN re-activate it, and remotely. Can the AMD PSP be rendered harmless by containment, to where when Running Linux, it is non-functional because Windows utilities aren't there to re-activate it?
In theory, yes. In practice, no.
If you want to be 'nefarious', all that HTTPS pushing that has been going on is actually a government supported conspiracy to help obscure their illegal spying on your computer hardware by ensuring all traffic is encrypted, thus making a particular stream of data impossible to discover, analyze and discuss when they *DO* exploit the backdoor they have in the hardware.
Furthermore, if the backdoor in question requires an application, processor core, drm, or ethernet packet/frame level trigger, it could be impossible to discover without having already been tipped off by a leaker with inside knowledge, since, as stated, everything is encrypted, and all that would be needed to enable a backdoor/dump state is an amazon/azure web services instance somewhere sending a packet in an otherwise valid stream of content which the Intel ME/PSP is looking for, possibly just by scanning memory space periodically for a certain set of 'trigger pages'. All that would be needed to do that, would be to ensure the processor reaches a state that triggers the ME to verify its memory (since it is assumed the ME/PSP is too slow to be scanning *EVERY* page fault. And then scan a particular series of page faults and/or memory address range to find its trigger, which then could simply watch for the incoming/outgoing TCP/IP stream (or raw ethernet frame, if it requires network level access to exploit/activate.)
Furthermore, the new 'process encrypted memory'/'memory coloring' support that all the new processors have would make it quite easy to keep even the most dedicated and paranoid security user from being able to scan their entire OS's memory space to watch for such activity, even if you knew the fingerprint of it. Outside of statistical measurements (like a certain memory pattern, registering pages of a certain order, etc. Most of which would be hard and resource intensive to verify on a 'live system' running at even a fraction of its full computing potential.) it would be almost impossible to catch such activities, and combined with all the other obscuration techniques being used/added to computers today, each actually makes us *LESS* secure in the trustworthiness/auditability of our computer systems than if we were to just use older hardware which had a clear memory space and just basic MMU fencing.
In my humble opinion, the only way to return to 'user trustworthy computing', is to step back about 10 years in CPU features/tech, use an embedded controller style design for the management engine (or, if it MUST be on the processor for power minimization purposes), a fully sandboxed EC with its OWN memory space, an IOMMU for CPU/EC fencing, and a limited and isolated pair of input and output buffers so neither side has unrestricted access to the other's memory space. This would make a lot of things, like the virtual hard disk/networking/kvm support more difficult to implement, but in the case that it is TRULY necessary, it would be better to have that as a separate logical unit, which can be enabled/disabled by the EC at boot time/via system toggle/on a real time clock timer, based on auditable and authenticatable firmware the user can choose to provision themselves.
If it was really just about 'protecting our warranty liability' like Intel and AMD both claim, so you can't damage the hardware/cause unexpected operation by running an intentionally modified firmware (possibly at a resellers behest), all that would be required is a hardware jumper, a verification key (burned in, like is currently done), and some sort of CPU 'text change', like report the processor via CPUID with 'Dev Mode Unlocked'. If the risk of hardware damage is so bad, include a warrant efuse as well and flag the CPU as 'Warranty Void'. Hell, just release the Intel K series/AMD Black series processors like that, permanent void fuse, and no firmware signature checking.
But doing things the smart way has never been either Intel or AMD's forte. For the history of dumb moves by each, just go read through their wikipedia pages.
This will likely be the last PC I ever get, and it was bought when Win7 was middle aged.
I've been interested in chip design for a while. If anyone plans to make an open source chip count me in!
Robust firmware-signing isn't the problem... robust firmware-signing that requires a key not under your own control is the problem.
That's my #1 beef with Android... Google is happy to bitch about my unlocked bootloader, but forces me to choose between leaving it unlocked, or locking it WITH THEIR FIRMWARE ONLY. I want to be able to flash my own firmware AND re-lock the bootloader with MY OWN key.
It's also why I don't particularly object to things like AACS implemented directly by a discrete codec chip, but hate when mfrs. rely on the OS & CPU to enforce it. If it's embedded in the codec chip, I can ignore its existence and just not use it. If it depends on the CPU for implementation, the mfr. is going to try and lock down the entire device. It's the difference between being forced to own a black box you can bury in a hole in the back yard & ignore, vs living in a police state where you're forced to live IN a black box under somebody else's control.
Dude *(BOTH) TRUSTZONE* *Samsung KNOX*
Every major CPU manufacturer is pulling the same shit.
TrustZone was actually the predecessor to Intel's ME picking up TrustZone like capabilities, which basically brought all of the Palladium initiative's features (as well as the Clipper Chip/Initiative's most important features) into the FCH/Processor itself.
Furthermore, even chips people think of as 'free' from this stuff, have it, although some of them allow it to be disabled (Raspberry Pi are permanently unlocked versions of the BCM SoC, which actually supports firmware signing and ME-type management utilizing the Video Core 4/5, which is basically Intel ME/TrustZone/PSP using a different CPU arch, and lacking an MMU.)
The only real way out of this is either a new startup company catering to exactly 'our' crowd, or crowdfunding a desktop RISCV/J[2,4,6]/OpenSparc motherboard and processor combo (SOCKETED, not solder down. Lose a few watts, leave open future upgrades/replacements.)
Interesting how this is news now just when AMD's new processors are a serious threat to Intel.
Lack of a 'failsafe' firmware/settings, and lack of an in-cpu trigger that can reactivate/bootstrap the PSP/Intel AMT from disabled state while the system is running, neither of which is out of the realm of possibility, even something as simple as 'if EC(Embedded Controller) disabled && cpu state == FF get BLOB from MEMADDR' Add that stuff could be hidden in a web script, or other piece of code. It only needs to trigger if the EC is shut down, meaning spurious attempts to switch it on while it is already running should not trigger it, and if it is not running, all it needs to do is verify the signature of the image at MEMADDR and if it is garbage data verification fails and the EC returns to dormancy until the next attempt.
Mind you this is a layman's high level conceptual of how this would be done, but I have to imagine an electrical engineering student, nevermind professional, could figure out how to implement this, either via uOps or low level logic to wake up an MMAPed asynchronous processor, have it check/clone a memory space before it is wiped out, and initialize a malicious payload, all without alerting the user to its presence. If you consider case history of Intel SMM and the viruses that got inside of it, causing systems to slow down. And just general random pauses in common consumer applications, including operating systems like windows itself (or in some cases linux, esp with a bloated desktop and going down an unoptimized codepath on your GPU...) it isn't impossible to thing even if the device was misbehaving/degrading peformance that the end user would be unable to discern the possibilty of it being a low level attack rather than high level software shortcomings.
Here is a congressman's views of the Fourth Amendment:
"You can't have your privacy violated if you don't know your privacy has been violated".@0:54
Now who is the traitor?
I immediately interpreted PSP as Playstation Portable and wondered why AMD even held the source code for Sony's game system in the first place!
If DRM hacks are so successful, then we don't need the source code or documentation? The fact that we DO need those things should be most telling about our bragging.
No AMD has ever had the feel of Intel to me.
Accepting something less because you are poor.
You know, that's argument ad hominem. It really doesn't matter *who* makes the argument; what matters is the merit of the argument. The argument is that security through obscurity isn't any good. It's an argument every security expert will agree with. In this case it's been already proven to be a vulnerability, in case of Intel. There's no valid defense AMD can use to defend their approach. ...so, for lack of valid defenses, let's use ad hominem...
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Yes it is.
But in the eyes of the company, those groups are considered fringe groups, people who have wider agendas.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
That really is the only sane conclusion.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
AMD - I know your PR weasels read this - do you understand that the sort of people who care about this issue are the sort of people who make buying decisions for companies? Your statement " "We have no plans on releasing it to the public," the company executives said in a tech talk, is arrogant and obnoxious. We were debating switching to Ryzen but fuck you, it'll be Intel all the way baby.
According to https://www.raptorcs.com/TALOS... Raptor Engineering is working on Talos II. They claim it "Libre-friendly, powerful, and competitively priced the new, POWER9-based Talos II takes flight in early August 2017!" so not long to wait before we can evaluate the specs and price. Debian GNU/Linux has a POWER9 port which I'd expect would run on such hardware.
Digital Citizen
I don't care about the code. I just want to know how to turn it off.
Seriously, what's a decent bypass for this? Ignore the onboard LAN and use an oddball gigabit NIC for which the PSP couldn't possibly have a driver?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
So the alien greys really are anal probing Americans?
Suppose you went into the BIOS/UEFI whatever and disabled the onboard ethernet. Then go out and buy an ethernet card that uses a different chip than the onboard port. Since there's no driver for that card in the PSP code, wouldn't that isolate it?
Well, I'm going to express my vote through my wallet. I'm not a fringe group - I'm a potential customer. A potential customer they have lost.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2