With the Intel In-Memory Analytics Accelerator (IAA) and Data Streaming Accelerator (DSA) introduced first with Xeon Scalable "Sapphire Rapids" processors, they can be a big performance win for some workloads but [1]can be a pain to setup and with limited software support . It also turns out that since a security advisory issued earlier in the year, current Intel IAA and DSA accelerators aren't safe for use within virtual machines (VMs) and that issue doesn't appear to be resolved until Diamond Rapids and Granite Rapids D processors.

Intel's [2]SA-01084 advisory issued back in May slipped under my radar at the time and also hadn't seen it discussed elsewhere. This high severity DSA/IAA advisory was reported as an escalation of privilege issue when having local access to a Xeon processor with these accelerator blocks. The recommendation in that bulletin is to restrict untrusted usage of the DSA/IAA devices from VM guests or third party applications.

What the Linux kernel ended up doing was [3]a mitigation of adding the Sapphire Rapids DSA and IAA accelerators to the VFIO deny list. The patch noted:

"Due to an erratum with the SPR_DSA and SPR_IAX devices, it is not secure to assign these devices to virtual machines. Add the PCI IDs of these devices to the VFIO denylist to ensure that this is handled appropriately by the VFIO subsystem.

The SPR_DSA and SPR_IAX devices are on-SOC devices for the Sapphire Rapids (and related) family of products that perform data movement and compression."

It's just not Sapphire Rapids IAA / DSA accelerators but back in May also confirmed for Emerald Rapids. The advisory was before the launch of Xeon 6 "Sierra Forest" but that is too using the same device IDs so it turns out to be affected and unsafe for assigning to VMs.

Hitting the Linux kernel mailing list last night was [4]a new patch series reaffirming that current IAA and DSA accelerators are not safe to assign to virtual machines. Those patches though add new device IDs for the "safe" accelerators that can be exposed to VMs. Those device IDs though are for Granite Rapids D and Diamond Rapids. So it would appear even the upcoming Xeon 6 "Granite Rapids" (non-D) processors with the existing IAA/DSA accelerator IP is also vulnerable to this security issue.

That patch series cover letter from last night notes:

"Due to a potential security issue, it's not safe to assign legacy DSA/IAA devices to virtual machines. This issue has been addressed by adding the legacy DSA/IAA device IDs to the VFIO denylist.

With the security issue fixed in newer DSA/IAA devices, which have new device IDs, these devices can be safely assigned to virtual machines without needing to add their IDs to the VFIOI denylist. Additionally, the new device IDs may be useful to identify any other potential issues with specific device as well in the future."

With only adding the new DSA and IAA device IDs appearing in next year's Granite Rapids D and Diamond Rapids, it appears at that point it should be safe for assigning those accelerators to VMs and not with upcoming Granite Rapids (non-D) or Sierra Forest AP which is unfortunate given the focus on the cloud.



[1] https://www.phoronix.com/review/intel-accelerators-linux

[2] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01084.html

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95feb3160eef

[4] https://lore.kernel.org/lkml/20240828224204.151761-1-fenghua.yu@intel.com/