How is it not illegal to do this without at least first ASKING the user for confirmation? I'd be annoyed but find it 'merely anti-consumer' rather than 'intentional destruction of property' if the BIOS refused to finish POST without the user confirming that yes, they want to sacrifice this CPU and make it (p)owned by $CORP.
Watch the video, yes there is a prompt.
Lenovo vendor locking Ryzen CPUs with AMD PSB
101–110 of 234 posts
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#102Earlier quoted context omitted.
Doesn't this one have a prompt? So if you choose "no" every time on startup, it won't blow fuses?
Will it boot if you select no?
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#103Earlier quoted context omitted.
The motivation from Lenovo's customer perspective is theoretically the customer knows this was the processor intended for the machine by Lenovo and nobody swapped it out in between the Lenovo factory and the customer's hands. Of course, no system is perfect so it's not a full guarantee and also there's the impact to the secondary market. But if you're an enterprise leasing these machines you don't care about the seco…
> The motivation from Lenovo's customer perspective is theoretically the customer knows this was the processor intended for the machine by Lenovo and nobody swapped it out in between the Lenovo factory and the customer's hands. Except that it works the other way. You can put a generic retail processor in the machine -- which will then ruin it by locking it to that vendor. No customer benefit exists.
> which will then ruin it by locking it to that vendor.
Only if they click yes. https://twitter.com/FedsAgainstGunS/status/14734795248054927...
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#104There are a couple of issues I see with this. First, the security argument is nonsense in my opinion. This "feature" only prevents an attacker from flashing a modified, malicious BIOS on to the server. But: If an attacker manages to flash a new BIOS to your server, you're already lost. That either requires physical access (which is bad), or access to the OOB / BMC / IPMI (which is equally bad, because those usually h…
> You could permanently kill an entire datacenter with that within seconds
Damn I bet someone perhaps a state player or a well financed group is able to do this, can't wait to see this happen...But how does anyone burn it remotely?
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#105Earlier quoted context omitted.
> a free architecture that doesn't include that shit There is nothing stopping RISC-V SoC/CPU vendors from tacking it on.
You're not wrong, but what's the motivation? With x86, backdoors and coprocessors were able to be added because both AMD and Intel were pretty much the only players in the ISA. Since they were effectively the only license-holders (and American multinational companies at that), the government had no problem forcing them to both add IME/PSP. With RISC-V, there is pretty much no such obligation. It's an open spec, there…
> ...the government had no problem forcing them to both add IME/PSP.
This is a false narrative, these management engines were added because large (corporate) customers of the major CPU vendors asked for them. Enterprise IT shops love stuff like this, anything to help them tame the unruly beast of asset inventory and management. This is the same reason things like iLO and DRAC exist, and they have all of the same types of bugs for the same core reason.
Not only does the government not want management engines, the ability to turn them off using HAP is courtesy of the US government (namely the NSA!) asking for a feature to disable it.
The main problem here is that the truth is boring, and the conspiracy theory sounds much more interesting.
https://www.csoonline.com/article/3220476/researchers-say-no...
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#106The problem is the AMD PSB functionality in itself. It should be considered malware like the Intel managament engine and thus refused by users. It's a second processor that runs a proprietary firmware signed by the vendor (that the user cannot modify or substitute entirely with a FLOSS alternative) that vendors can use do harm to the user. The AMD PSB can also be used to lock down a processor to enforce secure boot a…
> RISCV architecture (a free architecture that doesn't include that shit) Surely you can't think the architecture itself is the differentiator. x86 didn't have all of this security 20 years ago, give engineers a few years of time to throw some locks on a risc-v chip and it'll be Enterprise Ready™ in no time.
The good news is the main manufacturers of RISC-V are Chinese vendors that allow complete access to low level processor details. They generally don't lock down their products at all.
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#107Earlier quoted context omitted.
> a free architecture that doesn't include that shit There is nothing stopping RISC-V SoC/CPU vendors from tacking it on.
You're not wrong, but what's the motivation? With x86, backdoors and coprocessors were able to be added because both AMD and Intel were pretty much the only players in the ISA. Since they were effectively the only license-holders (and American multinational companies at that), the government had no problem forcing them to both add IME/PSP. With RISC-V, there is pretty much no such obligation. It's an open spec, there…
As others have pointed out the ISA has nothing to do with this. Intel could start building RISC-V CPUs with ME type technology tomorrow.
Sure you're open to buy RISC-V CPUs from China but how are you going to be certain that they have no backdoors?
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#108The problem is the AMD PSB functionality in itself. It should be considered malware like the Intel managament engine and thus refused by users. It's a second processor that runs a proprietary firmware signed by the vendor (that the user cannot modify or substitute entirely with a FLOSS alternative) that vendors can use do harm to the user. The AMD PSB can also be used to lock down a processor to enforce secure boot a…
RISC-V permits vendor extensions so absolutely nothing is stopping a vendor from creating PSB-like functionality in a RISC-V chip.
RISC-V is just an ISA.
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#109Earlier quoted context omitted.
If you read the two pages and you concluded that both AMD with their statement on Page 1 nor servethehome on Page 1 and Page 2 provided any information about how PSB works I can't help you.
Or that commenter read and understood the description of how it works, and failed to see how it increases security in a meaningful way. I also struggle to think of a threat model that this protects against.
If something is not on your level of expertise you can always have a look for people that have the required level. It's just one search away.
https://blog.cloudflare.com/anchoring-trust-a-hardware-secur...
Re: Lenovo vendor locking Ryzen CPUs with AMD PSB
#110Earlier quoted context omitted.
> a free architecture that doesn't include that shit There is nothing stopping RISC-V SoC/CPU vendors from tacking it on.
You're not wrong, but what's the motivation? With x86, backdoors and coprocessors were able to be added because both AMD and Intel were pretty much the only players in the ISA. Since they were effectively the only license-holders (and American multinational companies at that), the government had no problem forcing them to both add IME/PSP. With RISC-V, there is pretty much no such obligation. It's an open spec, there…
The motivation for other manufacturers is exactly same as the motivation for AMD to do this. To make more money by controlling resale markets. RISC-V wouldn't change any of those dynamics.