LWN: Comments on "Thoughts on software-defined silicon"

Thoughts on software-defined silicon

flussence — Tue, 07 Jun 2022 18:52:41 +0000

> I don't see how this could be seen as a ripoff, if Intel is clear about what you get when you purchase the processor.

Intel's customer isn't you as an individual. These things are laundered through the retail and system-builder industry, and those middlemen are under no obligation to be clear or honest about this DRM if it'll make them an extra buck.

The Apple situation just reinforces that: they *do* advertise and sell direct to end users, so they aren't going to intentionally build lemons and cut corners simply because they don't have the responsibility-laundering arrangements in place to get away with that.

Thoughts on software-defined silicon

jem — Mon, 23 May 2022 08:33:41 +0000

I don't see how this could be seen as a ripoff, if Intel is clear about what you get when you purchase the processor. What worries me is that people are not objecting to monopolistic pricing when you can't see it, but feel ripped off when they find out that a product is hiding additional capabilities that weren't in the purchase agreement in the first place.

I don't think we should be worried about Intel being a monopoly. To me it seems like they are gradually becoming the underdog, with AMD being competitive again. Apple has also proved that it is possible to make Arm processors that are competitive in general purpose computing, and with increasing distrust between China and the US, I wouldn't be surprised by a flood of powerful Chinese RISC V chips on the market in the coming years.

Thoughts on software-defined silicon

littoral — Mon, 23 May 2022 08:00:31 +0000

Intel is planning to rip off its customers, by selling them hardware that they can't use unless they pay an additional "ransom".
This kind of ripoff - pioneered, I believe, by IBM in the 1970s when it had an effective monopoly on certain kinds of peripherals - only works when a company has a monopoly. In a free, perfectly competitive market, the price of a product will be the cost of producing and delivering it, plus the reasonable profit margin that the manufacturer needs to stay in business.

It follows that the best defense is to make sure that AMD remains a viable competitor.

AMD efficient ECC

sdalley — Wed, 02 Mar 2022 20:39:04 +0000

Thanks for this. I've just seen the Gigabyte B550I Aorus Pro which does ECC and is miniITX too. Would make a nice low-dissipation system with a Ryzen 5650GE Pro APU.

But, my, how prices for this kind of stuff have shot up over the last few years...

Thoughts on software-defined silicon

anton — Wed, 02 Mar 2022 18:53:12 +0000

We use whatever is available at a good price. In our 5800X box we use 4 Kingston KSM32ED8/32ME.

AMD efficient ECC

anton — Wed, 02 Mar 2022 18:50:03 +0000

Asus and Asrock mainboards, and some Gigabyte ones support ECC on AM4 boards. AFAIK all CPUs are good except the non-Pro APUs. We have a Ryzen 1600X, 1800X, several 3900X, and a 5800X all working with ECC.

Thoughts on software-defined silicon

bblacksr — Tue, 01 Mar 2022 12:55:19 +0000

It seems this would be a bad business decision in the long run with many alternatives possible like ARM or Risc-V much less other competitors.

Thoughts on software-defined silicon

eean — Sun, 27 Feb 2022 03:07:24 +0000

> I could kind of see the justification for this if it was running the hardware harder and making it more likely to fail within the warranty period

yeah the Tesla battery thing actually might make sense since not fully charging the battery is better for its longevity and one presumes/hopes that as the battery ages unused cells can be cycled in as others wear out. so you're basically paying extra to optimize for range instead of longevity.

Hard to imagine Intel having something analogous to this though.

Thoughts on software-defined silicon

flussence — Sat, 26 Feb 2022 05:17:37 +0000

We *almost* had a chance to see that: Zen2 chips emulate a few instructions (BMI2 set) in microcode, and they're pitifully slow to the point of being better to hand-roll in C. If they could've fixed it in an update it would've been interesting news… but maybe they just didn't care for such a niche thing.

Thoughts on software-defined silicon

flussence — Sat, 26 Feb 2022 05:09:15 +0000

> I had a 3-core AMD a while back (just scrapped it), and I understood that a lot of these chips were actually 4-cores with a core disabled.

I had one of those too. Stable as a rock with the extra core enabled for 12 years now, and it could even handle overclocking on top of that. The weird BIOS dance to unlock it put me off ever trying to run Coreboot on the thing though.

Thoughts on software-defined silicon

nybble41 — Fri, 25 Feb 2022 19:06:50 +0000

As long as we're speaking in analogies, it's more like *buying* (not renting) the building but the seller only gives you the key to the first two stories. You are, after all, *buying* the entire CPU, even if parts of it are disabled by software keys.

The difference being that it's not a crime to pick or drill out some locks in your own building to access the upper floors. If you were actually renting the building (CPU) that would be a different matter. (And, of course, that the software locks in question are considerably more difficult to either pick or disable than, say, the lock on your average bank vault, much less a normal high-rise.)

Thoughts on software-defined silicon

geert — Fri, 25 Feb 2022 18:58:29 +0000

> If this building is analogous to a processor, how has constructing the other 8 floors consumed scarce resources? It costs about the same to build a 10 story building as a a 2 > story one if they're like processors.

The "10-story" processor still requires more raw material (silicon + whatever else for doping, etching, interconnects, ...). Plus, you can fit more "2 story" processors on the same wafer, so there's a processing cost, too.

Thoughts on software-defined silicon

giraffedata — Fri, 25 Feb 2022 17:02:49 +0000

If this building is analogous to a processor, how has constructing the other 8 floors consumed scarce resources? It costs about the same to build a 10 story building as a a 2 story one if they're like processors.

And that's why the the owner doesn't make you pay for all 10 stories if you don't need them.

And the only reason he doesn't go ahead and let you use the other 8 anyway is that locking you out of them is the only way he can know you're telling the truth when you say you're willing to pay for only 2 stories. Charging people for all the stories they're willing to pay for minimizes the price per story for everyone.

Coupling

smitty_one_each — Thu, 24 Feb 2022 18:51:44 +0000

There may be use-cases for being tightly bound to the vendor at the chip level.

However, it seems that, if we are unhappy with the risks of remote entities (public or private sector) being able to decide that we don't need to be operating anymore, that this looks like a tremendous threat vector.

Which invites the question of what open chip manufacturers exist that Linux can target.

Thoughts on software-defined silicon

nim-nim — Thu, 24 Feb 2022 10:39:44 +0000

Not really, for something that only needs minimal interaction with the rest of the kernel. Which should be the case for something that just loads a key.

Thoughts on software-defined silicon

atnot — Wed, 23 Feb 2022 23:52:45 +0000

> The reason for this is because defects happen (semiconductor chip joke for free, right there). If you have a problem in a redundant part of you chip, you can close it off and sell the rest of the perfectly good chip at a lower price point. Or lower the clockspeed, whatever.

As I pointed out elsewhere, the degree to which this happens is greatly overstated by semiconductor companies. True, not every chip is going to reach the full clock speed and have all cores working. But for one, especially on mature nodes, the majority of them do and also that doesn't apply for many other lines they already segment along like maximum memory capacity, ECC, software features like Ryzen PRO/vPro etc. The far majority of chips are cut down because they wouldn't sell at a higher price, not because they are defective in any meaningful way. They do this because relatively speaking, the individual chips are dirt cheap (tens of dollars), all of the cost is in the NRE.

> So now you have to track the certs for your chip in _addition_ to the chip itself! Alternately, maybe it stays once enabled sweet, now you have to track the _variants_ of the same chip.

It is generally rare for a cpu to leave a system after it gets put in and tracking per-device licenses already needs to be done for all of the other hardware like switches, BMCs, etc. so it's not really a lot of extra effort for them.

Thoughts on software-defined silicon

Trelane — Wed, 23 Feb 2022 22:57:31 +0000

> Processors there are already highly segmented, with dozens of SKUs that only differ in what fuses are blown in them in the factory.

The reason for this is because defects happen (semiconductor chip joke for free, right there). If you have a problem in a redundant part of you chip, you can close it off and sell the rest of the perfectly good chip at a lower price point. Or lower the clockspeed, whatever.

Interestingly, this is the opposite: it had _better_ have passed qual, but now it is walled off until the customer pays up.

> can be a real benefit for enterprise customers, as they would presumably need to order and stock fewer CPU variants.

On inventory: presumably this will need to be locked to the exact processor. (Or how else do you prevent copying the cert and enabling the functionality on _another_ chip? Maybe phone home? Contact a flex_lm install on your network?) So now you have to track the certs for your chip in _addition_ to the chip itself! Alternately, maybe it stays once enabled sweet, now you have to track the _variants_ of the same chip.

I don't see the upside honestly.

Thoughts on software-defined silicon

Trelane — Wed, 23 Feb 2022 22:34:39 +0000

I was pretty excited at first. I'm a fan of pushing software to the edge of hardware.

Unfortunately, this isn't Software Defined Silicon so much as Software _Deleted_ Silicon.

Thoughts on software-defined silicon

jezuch — Wed, 23 Feb 2022 13:50:14 +0000

> And, of course, there are dodgy web sites out there demanding payments for access to their content.

I see what you did there :)

Thoughts on software-defined silicon

nilsmeyer — Wed, 23 Feb 2022 08:38:24 +0000

> E-waste is definitely bad and nobody (to within experimental error) really enjoys re-selling parts.

I'm sure there however are people who enjoy having used kit available at a discount.

> The concern is that Intel might decide that you only get to have an i9 if you pay them $5 a month or something, and if you stop paying then it goes back to being an i5. As far as I'm aware, there is no law or regulation which unambiguously says they can't do that.

Yes and there are a few more things they could do, for example only sell the most basic feature set (single core x86-64) and then sell all the additional capability at a monthly fee structure. And they can decide to on longer rent the features out unless you get a new CPU. Getting downgraded to an i5 may not be so bad, getting downgraded to a 1 core i3 with no turbo probably renders the machine almost unusable and with zero resale value - though at this point you're likely renting / leasing the whole thing anyways which means it's no longer really your computer.

Thoughts on software-defined silicon

NYKevin — Wed, 23 Feb 2022 04:28:00 +0000

E-waste is definitely bad and nobody (to within experimental error) really enjoys re-selling parts. The concern is that Intel might decide that you only get to have an i9 if you pay them $5 a month or something, and if you stop paying then it goes back to being an i5. As far as I'm aware, there is no law or regulation which unambiguously says they can't do that.

Thoughts on software-defined silicon

IgorTorrente — Tue, 22 Feb 2022 17:48:23 +0000

Complementing the sdalley question.

Which ECC Ram kit are you using?

Thoughts on software-defined silicon

geert — Tue, 22 Feb 2022 09:46:56 +0000

Except that the unused cloud server capacity would be rented to someone else.

Software-defined silicon is like renting the first two floors in a 10-story office building which is otherwise vacant: if you pay more, you get access to more floors; if you don't, the other floors stay unused. But the other floors have been constructed anyway, and thus have already consumed (scarce) resources.

Thoughts on software-defined silicon

klossner — Tue, 22 Feb 2022 01:28:30 +0000

Many decades ago, my employer leased IBM 370/148 serial number 1. It was a lease not a purchase so we paid a monthly fee for the computing resource, and the fact that increasing RAM could be done by paying more each month to have a jumper moved was not philosophically troubling. It was analogous to renting a cloud server today.

Thoughts on software-defined silicon

mr_bean — Mon, 21 Feb 2022 23:31:54 +0000

I'm possibly alone in not seeing a massive amount of harm in this.

IF I can do the equivalent of buying, say an i5 12600k (currently on sale for about £280 = USD 380) and later upgrade it to an i9 12900K (currently retailing about 2x the 12600k) by just paying the differential in price I've potentially saved on buying a whole new 12900K and having to pass on the 12600K on eBay, or wherever, then I think there is a gain for me as well.

I'm much more worried about e.g. Lenovo using the features in AMD Ryzen chips to lock CPUs to Lenovo boards thus ensuring they have almost zero resale value if one happens to want to upgrade the CPU in a Lenovo PC.

Granted 99.99% of users upgrade at the granularity of "Whole PC" but Lenovo's move seems way more sinister than Intel's

Thoughts on software-defined silicon

jhhaller — Mon, 21 Feb 2022 16:20:38 +0000

HPE is doing this today with Greenlake. In order to sell to on-premise customers with a need for variable compute capacity and to prevent them from fleeing to the cloud, they deploy more hardware and let you activate that additional hardware for a fee. I'm not sure how this works on the back-end, if they have worked out a deal with Intel to get unactivated chips for a lower price, or if they just expect that people will buy the extra capacity once they have it. But, this is the kind of thing they could to with activation codes to ensure that the processor couldn't be used without activating it.

Thoughts on software-defined silicon

gnb — Mon, 21 Feb 2022 13:40:06 +0000

Whether the difference is really invisible depends a lot on the implementation: are the feature enablements being sold liable to expiry or revocation by the vendor? If so the difference between that and actually owning the feature seems pretty clear-cut. I suspect what is making a lot of commenters on this article uneasy is a suspicion that this is part of a move to a rental model.

Thoughts on software-defined silicon

BirAdam — Mon, 21 Feb 2022 12:38:36 +0000

Intel is preparing to license not just x86 but also their own designs. People will be able to buy different brands of the same chip (potentially) and some may not be crippled.

Thoughts on software-defined silicon

bblacksr — Mon, 21 Feb 2022 12:04:38 +0000

Maybe in the long run they may find themselves loosing market share to more open hardware like RISC-V or something else.

sometimes it's just a sale/negotiatin tactic

eliezert — Mon, 21 Feb 2022 10:35:38 +0000

Over a decade ago I worked for a HW company that had FW support for enabling features by a signed certificate.
On every cycle of the HW, what would eventually happen, is that all vendors who integrate the HW got the company to agree to include "100% attach rate" as part of the cost.
So there weren't really any certs installed by end users, it was (in my opinion) just something sales people can give as part of the negotiation tactics.
I recently looked at a product that includes such HW and to this day it lists these features as optional and enabled by a certificate even though it comes pre-installed and as a user I did not pay anything additional for it.

Thoughts on software-defined silicon

taladar — Mon, 21 Feb 2022 09:34:49 +0000

You should read the article. It is not about actual software defined hardware, just about enabling features in hardware with licenses.

Also, do you really think people somehow make fewer mistakes just because they are designing hardware instead of writing software?

Thoughts on software-defined silicon

marcH — Mon, 21 Feb 2022 09:01:42 +0000

> When you couldn't power all the transistors on the chip simultaneously for thermal reason the ability to pick between features A, B, and C ...

This problem has already been solved and it has not been solved by turning off features:

https://en.wikipedia.org/wiki/Intel_Turbo_Boost

Thoughts on software-defined silicon

willy — Mon, 21 Feb 2022 04:54:05 +0000

Sorry, that design didn't feature the redundancy. That was added in the next generation,

https://parisc.wiki.kernel.org/index.php/File:Isscc_cache...

Slide 20 is where they start talking about the yield improvement features.

Thoughts on software-defined silicon

timrichardson — Mon, 21 Feb 2022 04:35:40 +0000

IN pricing theory, you want to extract the maximum value. If you sell a product at only one price, you are forced to compromise at both ends: there are potential customers who would pay above your marginal price, so are potentially profitable but don't buy because your offered price doesn't meet the value they see in the product, and you leave money on the table from customers who have more value in your product than what you charge; they would have paid more if you asked, but you didn't.

The conventional answer to is create differentiated products at different price points. Intel does this, nothing new. It is commonly accepted that this is something like an happy accident of the variation in how CPUs are made. A comment above says that this is greatly exaggerated but even if not, the distribution of different working cores is not a random accident: it would be a deliberately chosen manufacturing strategy affected by how the production process is configured. I doubt that Intel or AMD is very surprised by the output they get, and I expect they could tweak their production process to avoid nearly all locked cores, although at the cost of lower total output ( I have some manufacturing experience behind that comment, but it think it is not a controversial statement). The difference between accepting binned manufacturing output or achieving the same thing with software seems really invisible to me. I find it ironic that a computer science community is having trouble with the concept of abstracting hardware into software.

Thoughts on software-defined silicon

timrichardson — Mon, 21 Feb 2022 04:20:13 +0000

Sounds very similar to resizing an AWS virtual server as needs grow; in other words, a very popular approach.

Thoughts on software-defined silicon

marcH — Mon, 21 Feb 2022 03:12:05 +0000

> It is possible (I haven't run the numbers) that they are running an "airfare-style" business model, where:

Breaking news: "premium" products yield higher margins. You've described how pretty much every industry works. The reason SUVs cost more that minivans in the USA right now is not because they cost more to manufacture, it's only because more people want SUVs more, etc.

What is special here is the frustration to hold something physical in your hand and owning only _part_ of it. For some curious psychological reason it feels _more_ frustrating than owning _none_ of it (like for instance: when some device is unusable without some cloud subscription)

Thoughts on software-defined silicon

nix — Mon, 21 Feb 2022 01:06:40 +0000

> When you couldn't power all the transistors on the chip simultaneously for thermal reason the ability to pick between features A, B, and C (either of which can be enabled but not all simultaneously) make such scheme pretty attractive. You couldn't do that with millions of SKUs but can easily achieve with million of [potential] licenses.
> And in that case the ability to enable features without license would become actively harmful: enabling all features simultaneously would just fry the chip

Yes, but... modern chips have been past this point for at least a decade. It wasn't solved with a licensing system: it was solved by having power management circuitry on the CPU that adjusted things (usually the operating frequency and voltage, but it is perfectly possible to imagine it also adjusting semi-invisible microarchitectural features like the number of execution ports) such that your code would keep running, just slower. Boost mode etc is the same thing: the fewer cores busy, the faster they're run, and even with lots of cores busy you can run fast briefly until the power management system turns down the CPU frequency to keep things cool enough. This is obviously *vastly* more efficient and flexible than some clunky licensing system would be: it allows for dynamic adjustment, which is something no licensing system like this could ever handle.

No, this is all about getting to make one SKU and sell it as several and allow upselling lower models to higher without needing hardware replacement. Shame that doing so requires cryptographic locks in the chip. (I doubt that anticircumvention measures are meaningful here: modern CPUs are almost impossible to analyze at the level you'd need to to crack this open anyway, or people would already have extracted much more significant private keys for firmware signing etc. Nobody has.)

Thoughts on software-defined silicon

willy — Sun, 20 Feb 2022 17:13:42 +0000

You're assuming that defects in L2/3 can only be worked around by disabling noticable chunks of the CPU. I don't know how Intel handles it, but I'd encourage you to read a paper from HP on how they handled it twenty years ago,

A 500 MHz 1.5 MB cache with on-chip CPU

(there are various free copies of the pdf floating around the net; you don't need to pay for it)

You probably also want to consider what percentage of the die is L3 cache; over 90% on the high end models with a hundred MB of L3 cache.

Thoughts on software-defined silicon

Tobu — Sun, 20 Feb 2022 15:35:27 +0000

The activation trigger could be something like a CPU identifier wrapped in a signature from a key Intel controls, because why wouldn't they.

Thoughts on software-defined silicon

khim — Sun, 20 Feb 2022 12:00:58 +0000

> You can't "solve" the "problem" of locked hardware; it is not a technical problem in the first place.

Yes, but you can go in the other direction: use solution designed to solve economic problem to solve technical problem, too.

> As long as those economic incentives continue to exist, it is inevitable that Intel, and other chip manufacturers, will produce and sell locked hardware.

True, but they would use technical need to keep hardware from breaking as justification for what they are doing.