Intel Software Defined Silicon Driver Queued Up Ahead Of Linux 5.18

Intel's Software Defined Silicon (SDSi) driver is ready to be merged for the Linux 5.18 kernel now that it's been queued into the x86 platform driver's "for-next" branch.

Earlier this month I wrote about the latest activity that Intel's SDSi Linux driver was likely to land in Linux 5.18. Now barring any last minute change of course or objections from Linus Torvalds, it's pretty much guaranteed - intel_sdsi driver was queued into the "for-next" x86-platform-drivers Git branch this week, meaning it will be sent in as part of the new feature material for Linux 5.18 once the merge window opens earlier this month.

The x86 platform drivers maintainer reviewed the code and on technical grounds there was nothing at this stage to prevent it from being queued, regardless of personal feelings over this functionality that allows for passing cryptographic keys to the CPU for unlocking extra, yet-to-be-published features. So now that it's been reviewed by relevant stakeholders, the Intel SDSi Linux driver was added to platform-drivers-x86.git's for-next code.

While some reader comments in past articles have tried to express hope/pressure to get Linus Torvalds to reject the driver, unless he can find some technical objections to the new driver code it's now on a path that it will be added to Linux 5.18. Torvalds does a good job of leaving the politics out and evaluating the code on technical merits... Just as there are mainline Linux kernel drivers supporting HDCP content protection, support for out-of-tree/proprietary kernel modules, etc. It's unlikely Torvalds would reject this driver over personal feelings without any valid technical argument (just as the x86 platform driver maintainer has since stated he personally doesn't necessarily agree with the driver either). As with the HDCP driver code and such, if you don't like it, then don't use it, build your kernel without it, and/or with your purchasing power avoid buying hardware supporting it. This driver is not locking down any functionality of your current processors or imposing any new restrictions on hardware you already own.

Making the situation murky is that Intel hasn't announced how they plan to segment their products with Software Defined Silicon. All we know for sure is that it will be used for crpytographic-based, software license activation of additional CPU silicon features. Given their prompt Linux upstreaming of this support, presumably it will be at least initially limited to their server/workstation processors. Whether this is for shipping some CPUs by default without AVX-512 to then allow it as an upgrade afterwards or something more fundamental like exposing extra CPU cores or cache remains to be announced by Intel. Various CPUs already fuse off some functionality depending upon the SKU, but Intel SDSi could now allow for possible software upgrades depending upon data center / deployment needs. It will be interesting to see how Intel SDSi plays out and if it has more merit than the Intel Upgrade Service from a decade ago that had similar ambitions, but long story short it's one step away now from the mainline kernel.

This intel_sdsi kernel driver fundamentally exposes a sysfs-based interface to user-space for writing an authentication key certificate (AKC) passed to it to the CPU's internal NVRAM, provisioning capability activation payloads (CAPs), and reading the SDSi state certificate. Besides the 500+ lines of kernel code, Intel is working on the user-space software side as well but yet to be published for which is what Intel customers will interact with for the actual Software Defined Silicon purchasing/activation process.