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!

By Jonathan Corbet
February 18, 2022

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)