Intel's Current IAA & DSA Accelerators Aren't Safe For VMs Due To A Security Issue

[phoronix]

Phoronix: Intel's Current IAA & DSA Accelerators Aren't Safe For VMs Due To A Security Issue

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 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...

https://www.phoronix.com/news/Intel-IAA-DSA-Security-VMs

[bezirg]

Again? These security issues are so many

[coder]

This seemed predictable. Accelerators run outside of a process and therefore it seems like it'd be challenging to ensure they obey all of the security rules to which processes are subjected. That stuff is hard enough to get right, when it's just ordinary software, executing in the standard OS model.

[emansom]

Security or planned obsolescence?

[coder]

Security or planned obsolescence?

It's definitely not planned obsolescence, when it affects CPUs they haven't even launched, yet!

Honestly, AMD's presence in the datacenter market has been so robust that I think Intel can't afford the reputational damage and ill will it would cause to pull any "planned obsolescence" stunts, these days. Plus, there's AmpereOne, Nvidia's talk of offering Grace for general purpose servers, and probably like half a dozen companies building RISC-V server CPUs. Competition among server CPUs is already heated and soon to really ignite!

[sophisticles]

Intel's 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.

The reason this slipped under Michael's radar is because it is an extra large nothing burger.

You need to have local access, i.e. physical access that is also running a VM.

That means it has to be an employee of the data center or company using these servers, and once someone has physical access to the hardware, all bets are off.

[coder]

The reason this slipped under Michael's radar is because it is an extra large nothing burger.

I'm not sure about your characterization, but someone doesn't think this is a "nothing burger" because:

"This issue has been addressed by adding the legacy DSA/IAA device IDs to the VFIO denylist."

Anyone who doesn't modify that VFIO denylist will not see the DSA/IAA devices and therefore won't benefit from them inside VMs. Regardless of the risk severity, the implications are very real to anyone running workloads that benefited from them.

Getting back to the details of INTEL-SA-01084, what they actually say is:

Description: Hardware logic with insecure de-synchronization in Intel® DSA and Intel® IAA for some Intel® 4th or 5th generation Xeon® processors may allow an authorized user to potentially enable escalation of privilege local access.

Doesn't say anything about physical access. It's not clear to me exactly what they mean by the phrase "privilege local access".

[sophisticles]

Doesn't say anything about physical access. It's not clear to me exactly what they mean by the phrase "privilege local access".

As far as I know local access is the opposite of remote access, in other words a person has physical access to either the network or server.

Intel employees found this vulnerability and Intel disclosed it.

I think it reinforces my stance because it took an Intel employee to find this problem, there has never been a report of it in the wild or any indication that anyone even would have known it existed if not for Intel.

Nothing burger, extra nothing, hold the onions.

[coder]

I think it reinforces my stance because it took an Intel employee to find this problem, there has never been a report of it in the wild or any indication that anyone even would have known it existed if not for Intel.

This logic is dangerous, because state-sponsored hackers would be somewhat protective of the more obscure vulnerabilities they discover and you'd expect they wouldn't necessarily release malware containing them into the wild. They would likely keep them in their arsenal of attacks reserved for high-value targets.