[HN Gopher] Lenovo vendor locking Ryzen CPUs with AMD PSB
___________________________________________________________________
Lenovo vendor locking Ryzen CPUs with AMD PSB
Author : virgulino
Score : 209 points
Date : 2022-01-16 18:01 UTC (4 hours ago)
(HTM) web link (www.servethehome.com)
(TXT) w3m dump (www.servethehome.com)
| jfim wrote:
| This different article from STH explains what the AMD PSB is,
| without having to watch a video:
| https://www.servethehome.com/amd-psb-vendor-locks-epyc-cpus-...
|
| > An OEM who trusts only their own cryptographically signed BIOS
| code to run on their platforms will use a PSB enabled motherboard
| and set one-time-programmable fuses in the processor to bind the
| processor to the OEM's firmware code signing key. AMD processors
| are shipped unlocked from the factory, and can initially be used
| with any OEM's motherboard. But once they are used with a
| motherboard with PSB enabled, the security fuses will be set, and
| from that point on, that processor can only be used with
| motherboards that use the same code signing key.
|
| Basically, the CPU once in that mode will only work with the same
| signing key, and cannot be put on a motherboard from another
| brand (or potentially another model from the same manufacturer).
| R0b0t1 wrote:
| Notably this seems to happen to CPUs that you might purchase
| yourself, which seems like a huge liability. If you somehow
| burn a $1000 CPU on a shitty mobo I can't see most people
| eating that.
| iratewizard wrote:
| My first thought was, is it really a big deal to do that to
| your laptop's cpu? Then I saw that they're doing this to
| desktops. My next thought was, people buy pre-built desktops
| still?
|
| Still really concerning to see Lenovo make boneheaded moves
| like this when they've had one of the better track records
| for manufacturers.
| seized wrote:
| Maybe not the worst track record but they have made other
| terrible choices...
|
| https://en.m.wikipedia.org/wiki/Superfish
| overtonwhy wrote:
| Most people buy pre built desktops. Partly because it's the
| only way to get a high end video card.
| kube-system wrote:
| Businesses almost exclusively purchase prebuilt computers.
| vetinari wrote:
| > My next thought was, people buy pre-built desktops still?
|
| If you are enthusiast and need a one or two desktops, then
| probably not. If you need to procure several hundred of
| them every few months, then probably yes.
|
| What this definitely will do is to affect the market price
| of these desktops once the lease (or depreciation time)
| runs out and owner will try to unload them on second hand
| market.
| mjrpes wrote:
| How does this affect the 2nd hand market? Will the buyer
| not be able to use the desktop?
| vetinari wrote:
| Cannot be bought as s source of spare parts, that you
| might use in different computers. At least not CPUs.
| INTPenis wrote:
| Thanks for the explanation, this is what I suspected but it
| wasn't made clear by the hysteria of the video because I really
| don't see the problem here.
|
| Most computers end up on the dump as one unit anyways. I've
| built a few computers in my time but never used an old CPU from
| one.
|
| And especially not one with that form factor that I probably
| buy as a wardrobe homelab purpose. I'd compare it to my Asus
| PN50 that does have a later model Ryzen so it might just make
| use of this PSB.
|
| Sure it sets an interesting precedent but then again a lot of
| CPUs in the business are welded to their boards.
|
| And this conspiracy theory of this being like Intel ME, or
| being used maliciously, is just an exciting answer to what
| probably has a much simpler explanation, like maybe this is
| vendor locking their product just like Microsoft Windows has
| been doing for decades.
| jacquesm wrote:
| > I've built a few computers in my time but never used an old
| CPU from one.
|
| I've routinely upgraded drives, graphics cards and memory to
| give an older system a new lease on life. Usually they're
| good for a couple of years after that. Essentially the only
| things remaining where motherboard, CPU and the power supply.
| chiph wrote:
| > or potentially another model from the same manufacturer
|
| This would allow an OEM/ODM to segment their offerings by
| having two or more sets of signing keys. "Oh sorry, that CPU
| only works in our entry-level offerings. You will need our
| enterprise-certified AMD CPU for your large server." "But it's
| the same socket!"
| amluto wrote:
| A _much_ nicer solution would be a move the static root of
| trust off the CPU package. The motherboard's EC could easily
| verify a BIOS signature before allowing boot with no CPU
| involvement whatsoever.
| rasz wrote:
| AMD CPUs are full SOCs nowadays. Everything is on CPU die.
| NablaSquaredG wrote:
| As far as I know, Intel does exactly that (or at least allows
| vendors to do that, I think HP does that)
|
| IIRC, in Intel's case, the chipset has the vendor keys burned
| into it. This is not an issue, as the chipset is not a part
| you would remove from the board and use elsewhere.
| my123 wrote:
| In Intel's case the ME as a whole is on the PCH.
| amluto wrote:
| Intel's or AMD's assistance is not needed at all. There is
| a rather boring flash chip connected by SPI to the CPU
| and/or PCH. One could interpose a microcontroller that
| verifies whatever it pleases on that SPI link.
| my123 wrote:
| That's the approach used by the Apple T2. On the Intel
| side, it's the chipset soldered on the motherboard which
| does that verification, so CPU swapping isn't affected.
| MertsA wrote:
| I think part of the motivation here is tying it in with the
| PSP and having the root of trust be the processor and not
| processor for some stuff and motherboard for others. For PSP
| related stuff it does make sense to centralize on AMD rather
| than having every vendor have their own implementation of
| some platform security standard. It's dumb to let
| motherboards effectively brick a CPU but there reasonably
| could be a way to have the root of trust on the CPU and
| extend that to firmware signatures so you could remotely
| attest BIOS versions, etc.
|
| I've mentioned this elsewhere but they could have just added
| some way of writing this signature out of band or allow
| bypassing it via a solder bridge on the top of the package
| like how SPD works on memory but require a separate interface
| for writing to it. Requiring a $10 I2C to USB adapter to
| change the key is not that onerous and it would be simple
| enough for OEMs to flash whatever they wanted on it and it
| could still be cleared for resale. For protecting against an
| APT doing shipment interdiction attacks quite frankly that
| sounds like a bunch of B.S. as all locking the key on the
| processor does is require the processor to be swapped out
| during an attack as well. If someone is going through the
| effort to intercept hardware in transit to flash custom
| malicious firmware on it, the cost of swapping the processor
| as well is not that extreme.
|
| If they're going to keep the strategy of blowing fuses on the
| CPU die then AMD should be the ones doing it and they should
| make a vendor specific SKU so that trying to figure out if a
| CPU is vendor locked or not isn't such a minefield.
| qmarchi wrote:
| See: The Sony PS3
| jevoten wrote:
| > OEM who trusts only their own cryptographically signed BIOS
| code to run on _their_ platforms
|
| It's not _their_ platform after they sell it. We should resist
| this trend of referring to items as still belonging to their
| manufacturers, legitimizing their control over them, while we
| are reduced to mere users, paying for items but not owning
| them. Let 's see how it sounds:
|
| > An OEM who wants to restrict their customers from selling
| their CPU, or buying one second-hand, will use a PSB enabled..
| richardfey wrote:
| I hate it when an article goes on without ever mentioning what an
| acronym stands for. PSB = Platform Secure Boot
| [deleted]
| josephcsible wrote:
| If you buy a Lenovo, then the CPU dies and you replace it with an
| unlocked retail one, will the motherboard blow the fuses in the
| new one and lock it too as soon as you power it up?
| rasz wrote:
| I think thats what the previous gen did, so most likely yes.
| kaladin-jasnah wrote:
| Doesn't this one have a prompt? So if you choose "no" every
| time on startup, it won't blow fuses?
| akelly wrote:
| Will it boot if you select no?
| judge2020 wrote:
| Yes https://twitter.com/FedsAgainstGunS/status/1473479524
| 8054927...
| NablaSquaredG wrote:
| There 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 have a remote KVM feature, so you could
| e.g. boot the OS into recovery mode)
|
| It does not prevent any other attacks, because you could still
| swap out the CPU. The servers usually just quietly burn the CPUs,
| so you wouldn't notice if the CPUs were replaced by an attacker.
|
| Second, this produces a lot of unnecessary e-waste. About 99% of
| all hardware (except HDDS) from datacenters is sold on the second
| hand market. Locked CPUs are essentially worthlese, especially if
| buyers or sellers don't know and throw the CPU away because they
| think it's defective.
|
| Third, this opens up a MASSIVE attack surface. Imagine if
| somebody finds a bug im the PSP (Platform Security Processor, a
| CPU inside the CPU that handles the locking thing amon g other
| things) and is able to burn arbitrary keys into the CPU. The
| attacker would randomly generate a key and burn them into the
| CPU. You could permanently kill an entire datacenter with that
| within seconds.
|
| Or if somebody manages to write a malicious BIOS version and
| flash it to servers which usually don't have a locked BIOS. This
| BIOS version would also burn a random key into the CPU with the
| same result: You can easily permanently destroy an entire
| datacenter.
|
| I think this is just AMD's greediness again in the cloak of
| "improving security"
| UI_at_80x24 wrote:
| >or access to the OOB / BMC / IPMI
|
| I've worked on a few SuperMicro servers that bundled OOB/IPMI
| onto the same NIC that is used for the LAN. 1 RJ45, 2 MAC
| addresses
|
| I will stab the bean-counter that thought this was an OK idea
| with a fork if I ever meet them.
| hnthrowaway0315 wrote:
| > 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?
| newsclues wrote:
| " You could permanently kill an entire datacenter with that
| within seconds."
|
| Nobody is going to care until this happens.
| akelly wrote:
| Good analysis. My question is wouldn't it be both more secure
| and more user friendly to burn the BIOS signing public keys
| into the motherboard chipset instead of the CPU?
| wmf wrote:
| This is basically what Google Titan does. Most vendors don't
| want to add an additional root of trust chip (and I'm not
| sure there are any good ones available to buy).
| SergeAx wrote:
| I wonder if it is possible to return such a system to the vendor
| based on a claim that the lock is irreversible decreased it's
| consumer value?
| firebaze wrote:
| Isn't Lenovo the problem? CPU vendors have to implement a secure
| enclave somehow to fulfill requirements from the content industry
| for quite some time now. But there never was a nefarious actor
| like Lenovo in this case to my knowledge.
|
| I understand from this case that my reasonable course of action
| is to inform my (non-IT-focused) peers and friends that they
| should avoid Lenovo by explaining the reason behind it (your
| device is worth less, since you won't be able to install linux or
| a Mac Clone!) to them.
| [deleted]
| alerighi wrote:
| The 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 and thus don't let you run an unsigned operating
| system, i.e. no longer allowing you to run Linux on your machine
| that comes out of the factory with Windows preinstalled. That
| would be a very very bad thing.
|
| Unfortunately both for Intel and AMD you don't have choices these
| days. I'm hoping someone develops a processor based on the RISCV
| architecture (a free architecture that doesn't include that shit)
| to be used in a computer entirely under the control of the user
| (hardware and software) and not the corporation that makes it.
| kube-system wrote:
| > It should be considered malware like the Intel managament
| engine and thus refused by users.
|
| Well, that clearly didn't happen with ME. Intel's market share
| gradually _grew_ for the decade after ME was introduced.
| mjg59 wrote:
| You're conflating two different things - AMD's Platform
| Security Processor (PSP) and Platform Secure Boot (PSB). PSP is
| broadly equivalent to Intel's ME, but lives on the CPU package
| rather than in the chipset. PSB is equivalent to Intel's Boot
| Guard, a feature that verifies that the system firmware has a
| valid signature before letting the CPU boot it.
|
| Both Boot Guard and PSB prevent you from modifying the system
| firmware (and, say, putting Coreboot on there), but because
| Boot Guard is implemented in the ME, and because the ME is in
| the chipset, not the CPU, you can take CPUs out of Intel-based
| systems and transfer them to somewhere else. If you do the same
| with a PSB-fused AMD, the firmware on the new board won't be
| signed with the same key and it'll refuse to boot.
|
| None of this technology provides any real way to prevent you
| from booting Linux. If vendors wanted to do that, they could
| already just ship firmware that only supported the Windows
| signing key and didn't let users enroll new keys. They don't
| need PSP, ME, Boot Guard or PSB to do that.
| Retr0id wrote:
| > a free architecture that doesn't include that shit
|
| There is nothing stopping RISC-V SoC/CPU vendors from tacking
| it on.
| smoldesu wrote:
| 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 is no licensing fee and there isn't an
| obligation to add hardware susceptibilities. Chinese
| companies will (and are) manufacture chips like this at the
| lowest cost possible, likely eschewing any black-box m53s
| running Minix that you'd find on an American CPU. It also
| opens the possibility for more bespoke chip designs (as it's
| a modular ISA), and hopefully dividing the market between
| security-conscious products and consumer ones will stop _all_
| devices from being digitally wiretapped.
|
| It's all speculation right now, but it's highly unlikely that
| RISC-V will be pozzed in the same way x86 or even modern ARM
| clusters are. There's too much competition, too much money to
| be made, and too few incentives. Suffice to say, you're
| probably going to hear the three-letter agencies complaining
| about "unsafe Chinese chips" soon or something equally
| stupid.
| Godel_unicode wrote:
| > ...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...
| smoldesu wrote:
| Why are management engines not delegated to
| professional/enterprise machines only then? Seems like an
| awful lot of money to waste putting specialized hardware
| into every machine you ship if only a fraction of the
| users will actually ever take advantage of it.
| supernovae wrote:
| economy of scale. Cheaper by volume and priced on
| utilization.
|
| There was a time when HP sold servers that could be up to
| say, 8 cores but only two were on by default and you
| cloud license the rest. It was cheaper to shop the
| hardware and software gate it rather than limit it and
| have a process in the middle.
| ndiddy wrote:
| Why does Intel, a company known for its extensive price
| discrimination (see ECC memory support, hardware
| virtualization, FPU support in the 90s) still put ME in
| all of its consumer CPUs when it's only useful for the
| enterprise market?
| klelatti wrote:
| 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?
| kube-system wrote:
| 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.
| Terry_Roll wrote:
| Well its only a question of time before someone starts
| targeting the Intel vPro Management Engine and AMD PSB to alter
| CPU abilities using variations of code like that found on
| Github below. https://github.com/mostav02/Remove_IntelME_FPT
| https://github.com/rootkovska/x86_harmful/blob/master/x86_ha...
| https://github.com/corna/me_cleaner/blob/master/me_cleaner.p...
| sedatk wrote:
| These would only help the power users, not the remaining 99%.
| BoorishBears wrote:
| Trusted computing environments only hurt 1% of the users
| anyways.
|
| We live in a world where people talk about Thinkpads vs
| Macbook Pros, but for 99% of the world laptops are
| appliances they buy like we'd buy a toaster.
|
| They don't care that they can't run Linux, if anything
| onerous code signing requirements ala mobile devices would
| be great for the safety of their devices with minimal
| effects on what they can do.
|
| -
|
| I'm not saying I want the market for power users to die,
| I'm one of them after all, but I also feel like these
| conversations on HN are often disconnected from the reality
| most people live in...
|
| This isn't really a "they don't know better so they don't
| complain", this is a "even if they knew better they
| wouldn't complain"
| fartcannon wrote:
| The hypothetical homogeneous group 'they' you refer to
| doesn't exist. It's billions of people and 'they' feel
| many ways. By painting with a common brush, you shut down
| discussions of what could be and encourage fence sitters
| to give up. Let's talk about why it's possible, easy to
| do, and how to do it.
|
| The more fence sitters you convince that things are
| possible, pushes the fence further and further towards
| the other side.
| BoorishBears wrote:
| This is very feel good but falls short of making an
| actual point.
|
| > The hypothetical homogeneous group 'they' you refer to
| doesn't exist
|
| They do exist. Making wrong statements with conviction
| doesn't make it true.
|
| You can look Chromebook sales figures, you can look at
| the best selling laptops at major retailers, you can look
| at what's driving record laptop sales, look at price
| points that are soaring, look at the mobile space...
|
| -
|
| > It's billions of people and 'they' feel many ways.
|
| Which is why we draw conclusions based on a large sample
| size like I did above. You're never going to be able to
| consider billions of points of view, so yes, you need to
| try and find the common thread in their preferences and
| usages.
|
| -
|
| > By painting with a common brush, you shut down
| discussions of what could be and encourage fence sitters
| to give up.
|
| No, by painting with a common brush, you can have actual
| useful discussions about the reality of things, rather
| than espousing your own personal whims.
|
| -
|
| > Let's talk about why it's possible, easy to do, and how
| to do it.
|
| a) Where did my comment say it's impossible?
|
| b) It's not easy to do or it wouldn't have existed in the
| first place. The whole point of my comment is saying that
| you need to figure out how to do it _taking the current
| reality of things into context._
|
| If the world thought how HN does we'd already have bills
| banning IME and PSB. So it doesn't. You can't pretend
| that people actually are a little nudge away from caring
| about this, or you'll quickly find that you're wrong and
| nothing will have actually changed.
|
| -
|
| > The more fence sitters you convince that things are
| possible, pushes the fence further and further towards
| the other side.
|
| Again, what you could do if you believed that fence
| sitters were some large portion of laptop buyers is do
| what I've done, show some indications of this. Show us
| how niche efforts aimed at power users aren't the only
| rumblings about how awful locked down computing is.
|
| What you're doing is still painting a group with a large
| brush, except you're not even showing us where you got
| the paint.
| fartcannon wrote:
| Huh? I like your ideas, but I'm not painting. I'm saying
| "don't paint". If you think of it like a nice dividing
| line through the people who think stuff can change and
| the people who don't, the folks on the line are 'on the
| fence'. You see? If you can convince a few of them (not
| large swathes of them, just a few), then the line shifts.
| If we all do that, we can change a lot of minds for good!
|
| You get what I mean? So yeah, my recommendation is that
| we all talk like things are easy to make better, instead
| of saying, "too late its all over" because you'll
| encourage more people to try which I assume you agree is
| a good thing but if not, I guess to each their own.
| kube-system wrote:
| I disagree. Market targeting, segmentation, and consumer
| preferences are real things which can be and are
| routinely measured.
| jkepler wrote:
| Exactly the parent commercial it's point: market segments
| /can/ and do change sizes and their proportional
| relations. And more people are beginning to understand
| the importance of security for privacy in a world that is
| increasingly digital and dependent on information
| technology.
| jacquesm wrote:
| That's agreement, not disagreement.
| kube-system wrote:
| I am saying that the market for people who care about
| these types of things is objectively niche. Large
| manufacturers build what they build because they fund the
| research to know what to build. And they are successful
| at selling them because they were correct.
|
| There might be billions of people buying computers, but
| the set that has any opinion on boot code signing
| requirements is not large enough to cause any significant
| impact on the market as a whole.
|
| There are companies that cater to these niche markets,
| like Pine/Framework/System76/Purism. They are tiny. Dell
| sells more computers in a single contract than all of
| these other companies have sold over their entire
| existence combined.
| jkepler wrote:
| True. However, sometimes large buyers, such as
| governments or enterprises, change their policies towards
| purchasing requirements. For example, since 2013 France
| has had an Inter-Ministry Foundation of Free Software[0],
| which provides the preferred software to be used across
| France's government, as French law requires preference be
| given to free software (logiciel libre).
|
| What impact might occur if a government like France were
| to require in the future only RISC V architectures with
| free boot loaders, of if the US government or a large
| corporation required use of measured boot to see at boot-
| time if the boot code or subsequent OS had been
| compromised?
|
| With persistent threat actors and the falling price of
| processing power, I wouldn't be surprised if in the next
| ten years some larger organizations (or tens of thousands
| of small businesses) start demanding this kind if IT
| security from their vendors.
|
| [0] (in French, of course)
| https://sill.etalab.gouv.fr/fr/software and their repo,
| https://github.com/disic/sill.
| judge2020 wrote:
| > 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(tm) in no time.
| alerighi wrote:
| RISCV is an open architecture. If a manufacturer does that,
| simply don't buy the processor from that manufacturer and buy
| it from another. All your software will still be compatible
| since it's the same architecture.
|
| Otherwise with x86 is more complex: you can choose between
| Intel and AMD (that has bought the license for the x86
| instruction set - not something cheap to get), and both of
| them had their backdoor processor inside the computer (at
| least on Intel there are ways to disable it, as far as I know
| with AMD is more difficult if not impossible to do).
| pjmlp wrote:
| Assuming that the software is all available from source and
| can be recompiled.
|
| Only the base RISC V is guaranteed thanks extensions.
|
| Also you are forgetting that just like Android and ARM,
| there are other forces at play that don't make it as easy
| in practice as FOSS advocates wish for.
| orangepurple wrote:
| 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.
| pjmlp wrote:
| Bad news is that US doesn't want to have anything with
| them.
| userbinator wrote:
| With the (already?) expiration of x86 patents, I'd love to
| see a "pure" x86 implementation without any of the user-
| hostile crap, and see how far the community can take it; but
| sadly, the RISC bandwagon is diverting attention away from
| that.
|
| A CPU without the user-hostile features but still able to run
| the massive existing software base would be ideal.
| alerighi wrote:
| Would be too difficult to implement. x86 is a very big
| instruction that is impossible to implement with an
| hardware: both Intel and AMD processors in fact run inside
| a virtual machine that translates x86 instructions in an
| internal RISC instruction set that is manageable by the
| real CPU architecture. If Apple decided to move away from
| x86 and go to ARM to have their processor, and we are
| talking about one of the biggest companies, I don't think
| any community project will ever succeed in doing another
| x86 compatible CPU.
|
| On the other side RISCV instruction set is far simpler,
| being a RISC instruction set it decides to not have
| advanced optimizations in the processor (even better, none
| at all) and leave the optimization work to the compiler,
| that not only simplifies the processor, but also reduces
| the surface of attack of the processor (Meltown, Spectre,
| and all these attacks are just impossible on RISCV!). Of
| course that has a performance penalty, but since you
| simplify the processor you can just put more core in the
| saved space right?
| userbinator wrote:
| I'm not sure if you're being satirical, but open source
| x86 cores do exist --- they're around a 486 in terms of
| compatibility. Look up ao486 for example.
|
| What I'm referring to is the expiration of patents from
| the P6 era, which would mean all the uop-based stuff is
| now free to implement.
|
| What a lot of the RISC hype doesn't understand is the
| huge value in backwards compatibility --- you can have
| your "100% free" world but it'll forever remain niche. We
| need to accommodate the proprietary world if we want any
| chance of freedom winning; and not try to divide the
| world of computing.
| als0 wrote:
| RISC-V is not immune to Spectre and Meltdown because
| these are implementation vulnerabilities. Any CPU
| implementation that uses out-of-order and speculative
| execution has to constantly worry about introducing these
| holes.
| userbinator wrote:
| And on the other side, neither were early Atoms; but
| everyone knows what their performance is like.
| mnd999 wrote:
| Raptor CS are still making those Power9 workstations I think.
| Power9 is also a free architecture "without that shit".
| spamizbad wrote:
| 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.
| Dma54rhs wrote:
| It won't be considered malware because techbros have embraced
| Apples closed down systems and Microsoft and every other player
| is just getting up to date. This ship has sailed long time ago.
| LeoPanthera wrote:
| > no longer allowing you to run Linux
|
| Is this actually true? openSUSE is supplied with a shim
| bootloader apparently signed with Microsoft's keys, allowing
| the OS to boot on any machine with Secure Boot enabled.
| mjg59 wrote:
| Windows is signed with different keys to all other third
| party UEFI code, so in theory you could ship a system that
| trusted Windows but not anything else. "Anything else" would
| include the option ROMs on GPUs, so you'd never be able to
| plug in a new Nvidia, but if that's a price you're willing to
| pay you could definitely block Linux today.
| AnotherGoodName wrote:
| Could it be AMDs doing behind the scenes? I don't see the
| motivation for Lenovo here but I do see AMD asking vendors to do
| this to prevent OEM CPUs completing with retail CPUs.
| vel0city wrote:
| 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 secondhand market anyways.
| zrm wrote:
| > 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.
| judge2020 wrote:
| > which will then ruin it by locking it to that vendor.
|
| Only if they click yes. https://twitter.com/FedsAgainstGunS
| /status/14734795248054927...
| contravariant wrote:
| I suppose that's helpful if you trust Lenovo.
|
| I've permanently lost trust in them after they decided to
| include malicious root certificates in their systems.
| YXNjaGVyZWdlbgo wrote:
| The feature was implemented in 2017 the only vendors that are
| using it are lenovo and dell. With lenovo being the only one
| using it on lower tier cpus than epyc.
| newsclues wrote:
| Was it OEMs that asked for the feature or did three letter
| agencies pay AMD and Intel to back door all CPUs?
| monocasa wrote:
| CPUs being backdoored is orthogonal to this.
| newsclues wrote:
| The security processor is a black box. If the nsa wants a
| back door, could this functionality not be the
| justification for the security weakness created by
| installing the security processor?
|
| It's what I'd do..,
| monocasa wrote:
| The security processor is there and starting the boot
| process whether or not it's checking a per CPU key on
| die.
| chiph wrote:
| Perhaps not to back-door them, but to ensure when they (the
| government agencies) buy from Dell that the supply chain is
| intact and the BIOS hasn't been tampered with during
| shipping by a foreign agency. Like the NSA did to Cisco
| routers destined for international customers.
| rasz wrote:
| I imagine its Lenovo asking for lower prices on Chinese
| market bound CPUs and AMD being super happy killing secondary
| market after seeing Intel server/workstation CPUs flooding
| out of Asia.
| YXNjaGVyZWdlbgo wrote:
| It makes sense for server security as discussed by the same
| source as the op https://www.servethehome.com/amd-psb-
| vendor-locks-epyc-cpus-...
| rasz wrote:
| except those arent server chips
| YXNjaGVyZWdlbgo wrote:
| That's why I said in my initial comment that lenovo is
| the first vendor that uses it on workstation cpus. ie.
| Threadripper epyc is very much a server chip.
| monocasa wrote:
| It's probably both of their fault. Lenovo wouldn't do it
| unless there was something in it for them. I wouldn't be
| surprised if they get a better deal from AMD on these CPUs
| for being locked to a specific board (killing off their
| ability to be used in the parts reseller market).
| YXNjaGVyZWdlbgo wrote:
| It makes sense for server security as discussed by the same
| source as the op https://www.servethehome.com/amd-psb-
| vendor-locks-epyc-cpus-...
| captainmuon wrote:
| That link doesn't explain _how_ it improves security, as
| all mainboards of the vendor have the same key. All it
| does is prevent somebody from sneakily replacing the
| mainboard with a different brand! It would make more
| sense if the _board_ was bound to the specific CPU
| (assuming the CPU is the root of trust). But then you
| could just encase it in some kind of thermal epoxy...
|
| It's obvious that this is supposed to limit the second
| hand server parts market.
| YXNjaGVyZWdlbgo wrote:
| 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.
| monocasa wrote:
| 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.
| YXNjaGVyZWdlbgo wrote:
| 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...
| monocasa wrote:
| I'm a security researcher. PSB as described there is
| orthogonal to the specific policy of tying the board to a
| specific CPU key, as you can tell from per CPU keys not
| being in the hardware root of trust as described by
| cloudflare. In fact you can swap the CPUs across boards
| from different ODMs in your most recent citation, since
| the root is an AMD key that then verifies the off chip
| ODM cert in flash.
|
| I stand by my orignal statements.
| YXNjaGVyZWdlbgo wrote:
| If you really think PSB doesn't provide any security
| benefit or "improves security in a meaningful way" you
| should do more security research.
| monocasa wrote:
| I was pretty sure that I made it clear that the concept
| under discussion was using a hardware root of trust
| scheme like PSB to tie a specific CPU to a particular
| vendor's boards.
|
| As an aside I'm putting a lot of effort into staying
| civil; I'd appreciate seeing that effort be a bit more
| reciprocal.
| YXNjaGVyZWdlbgo wrote:
| PSB is there to protect you from a compromised
| motherboard it protects you from malware in your UEFI
| firmware. It's not even a vendor lock in it's signing key
| lock in that is used in that manner by AWS, Gcloud and
| Azure. Compromised UEFI Firmware is a constant point of
| failure in pentesting of the secure chain of trust. That
| you as a security researcher are dismissing the fact is
| honestly just unbelievable.
| Shadonototra wrote:
| lenovo again.. when it's not shipping with rootkits (they did it
| twice!) and bloatware, it's about limiting HW
|
| a company to boycott
| Ysraes wrote:
| Is there any laptop manufacturer that doesn't ship complete
| bloat/mal/spy/ware in their products?
| turminal wrote:
| All in the name of "security" of course.
| brink wrote:
| All this security is making me feel claustrophobic.
| userbinator wrote:
| It's been around a decade since Secure Boot first appeared and
| I remember well the opposition that had, along with a rallying
| cry based on the infamous Franklin quote. Unfortunately many of
| the opposition either accepted it or even defected, but the
| more this "security" stuff appears, the more I like that quote.
| It's succinct and gets the sentiment across very well.
| UltraViolence wrote:
| [deleted]
| amerikkkan wrote:
| metalliqaz wrote:
| Are there any that are _not_ manufactured in China?
| ginko wrote:
| VAIOs are assembled in Japan at least.
|
| https://us.vaio.com/pages/vaio-made-in-japan
| beefield wrote:
| Maybe Fujitsu?
|
| https://indianexpress.com/article/technology/tech-news-
| techn...
|
| Of course, I assume lots of components for those are made in
| China.
|
| Samsung might make in South Korea? Asus in Taiwan?
| infofarmer wrote:
| Do I have news for you about the device you typed this on...
| older wrote:
| Please share the news.
| CoastalCoder wrote:
| Out of curiosity, which vendors do you find acceptable?
| jsheard wrote:
| Dell have been vendor-locking their AMD CPUs the same way for a
| while now
|
| https://www.servethehome.com/amd-psb-vendor-locks-epyc-cpus-...
|
| Previously it was limited to EPYC chips (the huge server parts)
| but it's spread down the stack to Threadripper Pro (high end
| workstation) chips as well now
| billyzs wrote:
| User name checks out
| rasz wrote:
| You misunderstood. This is about resale of base components. Go
| to ebay and look up 2-3 generations old Intel chips - super
| cheap from China. With this you wont find cheap AMD parts since
| they will be locked to Lenovo motherboards.
| vel0city wrote:
| FWIW, they're not locked to Lenovo boards you just need to
| have a board that can be configured to not care about the
| PSB.
| NablaSquaredG wrote:
| This is not correct. The locks does happen on the CPU
| level. If the board cannot provide a BIOS with a valid
| signature from the key that was burned into the CPU, the
| CPU will refuse to boot (PSB prevents it from booting)
| Koshkin wrote:
| China is the new Japan now. Only 10x that.
| pengaru wrote:
| Apple/Foxconn?
| kiryin wrote:
| Oh the irony of fate...
| 1MachineElf wrote:
| While avoiding Chinese-made computer components approaches
| impossibility the deeper you go, one vendor I'd trust not to
| fool around with AMD's PSB is System76. Not only are they non-
| shady, but they also try to open the firmware of the
| motherboards they use. While their AMD systems aren't quite
| there yet, the laptops they sell are.
|
| https://github.com/system76/firmware-open
|
| https://github.com/system76/ec
| tiku wrote:
| Can't we just bridge the connection with a lead pencil like on
| the old CPUs haha
| mnd999 wrote:
| That Thundebird Athlon over clock was amazing.
| mjevans wrote:
| 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.
| akelly wrote:
| Watch the video, yes there is a prompt.
| judge2020 wrote:
| the prompt: https://twitter.com/FedsAgainstGunS/status/147347
| 95248054927...
| mjevans wrote:
| Thank you for the screencap, I wasn't about to watch a
| video to discover this.
|
| 1) It's WAY WAY too easy for someone to not really read
| this and just press Y to continue, like load setup
| defaults.
|
| 2) There should _not_ be a way of disabling the prompt (the
| popup even mentions you can do this.)
|
| 3) If ever there were a time for a simple math problem
| (like multiply two numbers and enter the result) to
| indicate a user had read and understood the prompt, this is
| it.
| robocat wrote:
| > There should _not_ be a way of disabling the prompt
| (the popup even mentions you can do this.)
|
| I think you are mistaken. I am presuming that the prompt
| is suggesting that you can disable the PSB security
| feature (in which case the prompt doesn't show, which
| seems very sensible).
| judge2020 wrote:
| Because this is on the marketing page or spec sheet that you
| see before you buy the product, thus it being bound to
| $manufacturer's board is a feature. It's the same reason Apple
| execs haven't been thrown in jail for selling iPhones that only
| run iOS.
| [deleted]
| aasasd wrote:
| Someone still buys Lenovo?
| hoppyhoppy2 wrote:
| Perhaps not in your social bubble, but Lenovo is the world's
| largest personal computer manufacturer by market share, with
| just under 25% of the world's computer sales (measured by
| number of units shipped)
| userbinator wrote:
| There is much irony in still calling it a "personal"
| computer...
| amelius wrote:
| And Apple at 9%.
| mtgx wrote:
| fnord77 wrote:
| I'm not up on CPU terminology. I read the article and I don't
| know what this means.
|
| What is "locking" in this context?
|
| What is the "AMD PSB" ?
| pomian wrote:
| AMD's Platform Secure Boot (or PSB)
| NablaSquaredG wrote:
| locking: At least some AMD CPUs (EPYC, TR PRO, Ryzen Pro) can
| have cryptographic keys burned into the silicon by the BIOS
| (Dell and Lenovo do that) Once a CPU has those keys burned into
| it, it is locked to motherboards of this specific vendor,
| because other motherboards don't have a BIOS that is signed
| with the cryptographic key that was burned in.
|
| PSB: Platform Security Boot
|
| PSP: Platform Security Processor (a CPU inside the CPU which
| handles e.g. the key burn in process)
| fnord77 wrote:
| what advantage does locking a CPU to a specific vendor give
| the vendor?
| rasz wrote:
| Cheaper region locked CPU for Chinese market.
| zrm wrote:
| Customers often want to upgrade the processors in their
| servers.
|
| Someone bought some Dell servers with 32-core processors.
| They upgrade to 64-core processors and have the old 32-core
| processors. You'd like to buy them to upgrade your servers
| which have 16-core processors. Sorry, even though the chips
| are otherwise completely identical, theirs came from a Dell
| and you have a Lenovo. But hey, you can buy the processors
| directly from Lenovo for only three times as much money.
___________________________________________________________________
(page generated 2022-01-16 23:00 UTC)