Thoughts on software-defined silicon

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

People are attracted to free software for a number of reasons, including price, overall quality, community support, and available features. But, for many of us, the value of free software is to be found in its ability to allow us to actually own and maintain control over our systems. Antifeatures in free software tend not to last long, and free drivers can often unlock capabilities of the hardware that its vendors may not have seen fit to make available. Intel's upcoming "software defined silicon" (SDSi) mechanism may reduce that control, though, by taking away access to hardware features from anybody who has not paid the requisite fees.

SDSi is a "feature" that is expected to make an appearance in upcoming Intel processors. Its purpose is to disable access to specific processor capabilities in the absence of a certificate from Intel saying otherwise. As the enabling patch set from David Box makes clear, the interface to the mechanism itself is relatively simple. It appears as a device on the bus that offers a couple of operations: install an "authentication key certificate" or a "capability activation payload". The certificate is used to authenticate any requests to enable features, while the payload contains the requests themselves. Unless this device has been used to store an acceptable certificate and payload, the features that it governs will be unavailable to software running on that CPU.

The SDSi hardware also maintains a couple of counters that track the number of unsuccessful attempts that have been made to load a certificate or enable a feature. Should either counter exceed a threshold, the mechanism will be disabled entirely; the only way to get it back will be to power-cycle the processor. Presumably, the intent here is to thwart attempted brute-force attacks against the SDSi gatekeeper.

Intel is clear enough about the purpose behind this new mechanism. SDSi will enable shipping CPUs with features that may be of interest to users, but which are unavailable unless additional payments are made. The restricted capabilities will be present on all shipped CPUs, but the customers, who might have thought that they own their expensive processors, will not be able to use their systems to their fullest capability without add-on (and perhaps recurring) payments to the vendor.

The benefits to Intel are clear. The company can do price differentiation among its customers in an attempt to extract the maximum revenue from each while simultaneously reducing the number of different hardware products it must carry in its catalog. The revenue stream from a processor will not necessarily stop once the CPU is purchased, and might continue indefinitely. The benefit for customers is not quite so clear. In theory, customers with minimal needs can avoid paying for expensive features they don't use and can "upgrade" their hardware without downtime if their needs change.

Also unclear is which features Intel intends to control in this manner. One can imagine all kinds of things, including the ability to access larger amounts of memory, higher clock rates, additional CPUs, specialized instructions, or accelerators for workloads like machine learning. Taken to its extreme (which the company would presumably not do, though one never knows anymore), an off-the-shelf processor might be unable to run anything more demanding than "hello world" until additional licenses have been purchased. There was a time when a floating-point processor was an add-on unit; perhaps we will find ourselves there again.

This business model is not new, of course; stories abound regarding early mainframes that could be "upgraded" by altering a single jumper. Tesla automobiles include a number of features, including basic capabilities like use of the full capacity of the battery, that only work if an extra payment is made; there is no shortage of reports that the company will disable those features when one of its cars is resold. Car manufacturers evidently want to extend this idea to, for example, requiring subscription payments to enable heated seats. The heating elements exist in the seats regardless, and the manufacturer sold them to the buyer, but the buyer still does not really own them.

Rent-based business models have been spreading through the technology industry for some time. Many of us no longer purchase and run our own servers; we rent them from a cloud provider (and, to the tell the truth, are often better off for it). Companies that are still in the proprietary software business are finding the monthly subscription model more appealing than simply selling software licenses. And, of course, there are dodgy web sites out there demanding payments for access to their content.

But the problem seems worse for hardware that has been purchased, and which the customer, on the theory that they own said hardware, may believe they can rightly use to its fullest capability. Our free software, which is supposed to enable that use, finds itself relegated to asking the hardware for permission to use the available features. It is a loss of control over our systems, yet another set of secrets hidden away inside our computing hardware and protected by anti-circumvention laws; if this approach is commercially successful, we will surely see much more of it.

It is hard to see a way out of this situation that doesn't involve making hardware free in the same way that we have done with software. Maybe someday it will be possible to order the fabrication of processors from free designs and at least be able to hope that the result will be lacking in deliberate antifeatures. But that is not the world we live in now, and it's not clear that we will get there anytime soon.

Meanwhile, SDSi is definitely coming to Linux; maintainer Hans de Goede has indicated that this work is on track to be merged for 5.18. There are not a whole lot of arguments that can be made against the acceptance of the SDSi driver; it simply enables another piece of functionality packaged with upcoming CPUs. The kernel community has not made a practice of judging whether it likes the "features" provided by a specific peripheral before accepting driver support, and it would be hard to justify starting now. So the Linux kernel will play along with SDSi-enabled CPUs just fine; it will be up to customers to decide whether they want to be as agreeable.

---

(Log in to post comments)