Yes, but without criminalizing individual's right to video recording in public - sometimes this is necessary when you're dealing with bullying or sociopaths (where covert body cameras can be highly effective). Same for exposing animal rights abuses in farm. You want to be gather as much evidence, preferrably video, as you can in those circumstances?
HN user
argb
All information taken from public sources on GitHub and elsewhere. I am not under any kind of NDA whatsoever.
Sorry for the comment spam, I am so outraged at what AMD is trying to do and the potential DMCA implications faced by recyclers wanting to unlock the 'bricked' EPYC processors.
All further comments will be posted in accordance with the HN guidelines, I admit I was far too angry at the time.
Wow, my comment about how devious people with NPD/APD are just got flagged. Does anyone know why this has happened? Have I broken any of the site rules here?
[Update] Double checked the site rules, not sure if mentioning that she might have a PD is against them or not.
It wouldn't surprise me that there are quite a few people out there who want information about such disorders suppressed. But I'm not really sure if that's 100% the case here.
But the USB charger manufacturers could do better by shutting down the output should arcing/sparking be detected. We already have this for 120V AC supplies, and it should be doable for 5V DC.
ARM based platforms such as Allwinner and Rockchip CPUs which are free of these security measures. Though the performance is very poor in comparison, however over the next few years the situation might improve.
Currently using an Ryzen at the moment, my next CPU is likely to be a used Xeon because of AMD's PSP nonsense, which has reached a new low with the EPYC CPU 'bricking'.
On the Intel chips the ME security has been cracked completely so in theory someone could write an open source ME firmware replacement, although this might require a hardware mod to bypass the signature checks.
Not had a single crash on the Linux open source drivers though, here my RX 550 is rock solid with excellent performance for the given hardware. We have two different Vulkan drivers and two different shader compilers to choose from, all open source.
I think the GDPR would make an opt-out requirement mandatory. Still you can always physically disconnect the module and likely there will be an aftermarket solution to disable whatever warning lights come on.
The EU requires the module to be powered off except in an emergency. So it's not in contact with cell towers all the time, except when it needs to make an emergency call. It's easy enough to detect the transmissions with simple hardware.
These aftermarket hacks should definitely be legal, but don't expect Tesla to provide any more online services such as automatic firmware upgrades. These would have to be done manually by the owner now.
One of the nice things about the terminal is that things stay consistent for decades or more - people are not chasing fashion trends all the time, as is happening with the Web and graphical UIs.
Nobody is being forced to use a particular style and color scheme and we don't have repeated redesigns which remove functionality for the sake of user friendliness or minimalism.
You absolutely can as an single individual, with that CMOS camera on your person. It's when we start using a networked database to store faces, this is when it should become unlawful IMO.
There's a big difference between a human brain and a vast 24/7 all-seeing database which can identify an individual out of millions of faces.
A stationary camera looking up up peoples faces 24/7 in a huge database is a very different thing to occasional photography by an individual, who only has a limited memory capacity.
So it's the pervasive always-on nature that makes it different.
Also on old AMD hardware (SMC based GPU/CPU?) there is a very critical time period JUST after the device comes out of reset and before the SMC starts to lock everything down. Then you can access 'secret' SMC registers through JTAG and read out the protected SMC ROM for example (just keep resetting the device over and over, while stepping the SMC address one by one). The SMC's CPU is a Lattice Mico32 (LM32). In the SMC ROM is a symmetric crypto key which used for authentication (SHA1).
The SMC ROM contains code to initialize the hardware before the PCIe links are brought up. One of the first things the SMC does after boot is read out the eFuse contents and program various 'write once' lockdown registers which are used to disable features within the chip. Once these registers have been written to they cannot be modified until a hard reset occurs. So you write to these before the SMU gets a chance to. Or you can halt the SMC itself, then write whatever registers you want and reboot it as nothing ever happened. That way you can override many of the eFuse related settings.
The above techniques might also work on PSP based CPUs/GPUs - so you need to access the JTAG interface ASAP after bringing the chip out of reset. I'm unsure if the SMC is still present on the PSP-based CPUs and GPUs, as I don't have any spare to test.
Double plus if it's for an environmental cause. That would be a PR disaster.
While I don't have the time to look at this myself, someone should really have a go at trying to crack this, here are some EPYC server schematics with the JTAG signals brought out to test points:
https://pbs.twimg.com/media/D3jU2ZuU8AE_JgS?format=jpg&name=...
AMD is unlikely to sue anyone trying to reverse engineer the JTAG interface, especially if it's for an open source project to unbrick CPUs! If they do the EFF is very likely to step in and defend you.
It could be done with some kind of JTAG mod-chip, but this depends on what kind of JTAG security they've implemented.
If you want to know where to start, search GitHub for 'KaveriPI', if you unpack AMD BIOSDBG.EXE you can find a complete list of processor registers. This is all from 2015 but the PSP is documented in there.
There's also a Microsoft Access database which has all the JTAG registers, but I don't have the time to decode the meaning of the fields... It is likely that things have changed since then but it still might be enough for a start.
Should the JTAG interface be protected then some kind of laser(?) fault injection might be required to open it up. I guest some of the eFuse bits can be overwritten, maybe there's a combination which can remove the lock. An innovative recycling company could work on making a jig to automate this somehow...
Some PSP JTAG stuff here (publicly available material from GitHub in 2015, fair use applies): 41469,3529,164000,164999,"SMU_PSP_efuse_ovr_tried",,1,0,0,0,50,"0000",0, 41470,3529,164000,164999,"SMU_PSP_FRA_pass_ld_err",,1,1,1,0,50,"0001",0, 41471,3529,164000,164999,"SMU_PSP_FRA_pass_ld_cor",,1,2,2,0,50,"0002",0, 41472,3529,164000,164999,"SMU_PSP_efuse_pdmb_aes_dis",,1,3,3,0,50,"0003",0, 41473,3529,164000,164999,"SMU_PSP_efuse_pcpu_dis",,1,4,4,0,50,"0004",0, 41474,3529,164000,164999,"SMU_PSP_efuse_ccp_cyph_dis",,1,5,5,0,50,"0005",0, 41475,3529,164000,164999,"SMU_PSP_efuse_FRA_en",,1,6,6,0,50,"0006",0, 41477,3529,164000,164999,"SMU_PSP_efuse_proto",,1,7,7,0,50,"0007",0, 41478,3529,164000,164999,"SMU_PSP_efuse_secure",,1,8,8,0,50,"0008",0, 41552,2352,164000,164999,"SMU_PSP_hard_resetb",,1,31,31,0,50,"101F",0, 41553,2352,164000,164999,"SMU_PSP_early_resetb",,1,30,30,0,50,"101E",0, 41554,2352,164000,164999,"SMU_PSP_slv_mbus2_reset",,1,29,29,0,50,"101D",0, 41555,2352,164000,164999,"PSP_SCAN_MODE_STICKY",,1,28,28,0,50,"101C",0, 41568,2352,164000,164999,"PSP_AEB_307_PCPU_RST_DLY_TDR_en_pclk",,1,15,15,0,50,"100F",0, 41569,2352,164000,164999,"PSP_AEB_304_PCPU_FORCE_rst_en_pclk",,1,14,14,0,50,"100E",0, 41579,2352,164000,164999,"PSP_Resetn",,1,8,8,0,50,"1008",0, 43605,555,164000,164999,"PSP_ENABLE_SPARE",,0,1,1,0,50,"0001",0, 43642,555,164000,164999,"PSP_SPARE",,0,7,14,0,50,"0007",0,
It becomes a problem when there's a monopoly or a duopoly of suppliers and there are no suitable alternatives on the market with similar performance characteristics. I believe then the FTC can get involved with antitrust matters if they are abusing their dominant position to prevent reuse/recycling.
With a criminal penalty via the DMCA for bypassing it, because encryption is involved. That's why I'm so angry and want companies employing such encryption to be prevented from doing so or face prosecution.
So if I wanted to modify my car to unlock performance that's usually OK and certainly has been considered moral for decades. But if I wanted to unlock a core in my Ryzen CPU, or just hardware hack my GPU (Radeon Vega and above) to make it do neat tricks, I now technically risk a FELONY because of the PSP encryption and the DMCA - even though I want nothing to do with cracking copy protection. That is enough to have a chilling effect and prevent neat stuff from being released.
AMD have gone as far as signing the BIOS* on their recent GPUs, so tweaking it may be technically illegal (assuming you could crack the signature, though)!
This is unprecedented, nobody ever risked a potential felony for wanting to look inside their car to see how it works, or modifying their household appliances.
We need to get together (on Twitter and other social media) to fight this and let consumers know what is happening, because if people did, especially the more technically minded enthusiasts/gamers, that would put pressure on AMD and others to stop.
Specifically for gamers, let them know it's likely a FELONY to unlock a core in their Ryzen CPU or Radeon GPU due to PSP crypto. Just as with the ink cartridge recyclers who have been prosecuted for breaking cartridge chip security.
* = Radeon Vega and later GPUs have a Cortex-A5 PSP which runs autonomously, executing the Trustonic TEE from the SPI BIOS chip at boot, once the signature has been verified. Yes a whole DRM operating system running on the GPU - if you want to see for yourself, take a Radeon Vega or later BIOS and run binwalk -e to extract the compressed TEE.
Although a PSP flaw is very unlikely to harm an individual user, it puts the US and it's intellectual property at risk from foreign actors such as Russia or China. And many engineering firms do not have the resources of the NSA to protect against such threats.
Additionally, a PSP or Intel ME related hack involving a SCADA system would not be discovered until it's too late, with potentially extremely severe consequences. AMD is advertising the processor as being a security device that is intended to enhance system security. If such a SCADA hack involving the PSP was to result in loss of life for example, what would AMD's liability be in such circumstances, where the 'security device' itself has enabled the system to be hacked in the first place? Taking into account that the 'security device' cannot be disabled by the SCADA operator, so they have no choice to use it.
That is why I believe the PSP and ME should be removed completely. Should that not be possible it should be replaced with a processor that is transparent to its internal operation.
In many jurisdictions the product has to be 'fit for purpose', should the PSP be cracked and a hacker able to use it to assist malware wouldn't that make AMD's product not fit for purpose???
AMD, you removed the TrueAudio block from your older Radeon GPUs, couldn't you cut the PSP and implement some of its functionality using logic instead of a CPU? So the first thing to boot will be an x86 core, as it did in the old days. A physical jumper can be used to disable the security functions and remote attestation (to a server on the LAN) can be used to determine if CPUs are running in secure mode or not? Thus satisfying the needs of corporate users?
Removing the PSP will eliminate the negative PR it creates together with the associated security risk of having a secret part of the CPU where malware can hide.
On GPUs HDCP functionality can be implemented with ROM-based microcontrollers as it did on older hardware?
AMD should realize they are tarnishing their own brand reputation with the inclusion of the PSP and the recent CPU lockdown.
Even though it's a server CPU that's affected by the lockdown, stories like this are definitely not well received by the enthusiast and gamer communities and draw attention to such anti-features like the PSP. Knowing that there's a special processor inside the CPU specifically designed to prevent you from unlocking cores, etc. would NOT be good PR for AMD at all. I am using a Ryzen system right now and I regret buying it, I wish I went with Intel instead. At least the management engine has been cracked, unlike AMD's AFAIK.
It's about time we looked into a legal response to this behavior, just as with John Deere farm equipment, it will likely not stop unless fines are imposed or some kind of consumer boycott occurs.
Regarding the CPU lockdown, even Intel wouldn't do such a thing. Surely isn't it anti-competitive to lock the CPU to a specific system in this way? What would the EU think about this regarding e-waste and recycling? And I believe in Australia the ACCC would crack down very hard on such shenanigans?
These kind of DRM-like 'security' features starting being implemented first with phones and consoles and then has spread throughout the entire industry like a cancer.
Many of the features of the AMD PSP could be implemented as hardwired logic, no need for a CPU for that. And thus no chance of malware being able to run undiscovered.
It's like Orwellian doublespeak, in fact the Platform Security Processor might well be making the entire system less secure. Because we cannot inspect the content of the eFuse ROM how do we know if a state level adversary has placed code in there to weaken the system security?
Note: On the nVidia Tegra platform the eFuse ROM can contain executable code to patch the boot-up process, as Nintendo has done with the Switch console. It's likely that AMD has such similar functionality.
So the PSP could be cracked, and then CPUs can be eFused with malware before shipping the server, and nobody would know that there's an easily exploitable vulnerability now present.
I guess one of the real purposes of the PSP is to protect AMD's security and prevent the user from unlocking disabled cores, boosting clock frequencies, retrieving HDCP keys, etc. on both CPUs and GPUs. So it's partly to prevent the owner from doing what they want with the hardware.