Thunderbolt 4 kommer i år. Dette er nyhetene

[Kurt Lekanger]

Thunderbolt 4 kommer i år. Dette er nyhetene

[1P4XZQB7]

Nå kan ikke [???] Intel legge inn et krav i en semi-åpen spesifikasjon som Thunderbolt at den skal være avhengig av en spesifikk prosessorfabrikant, nemlig Intel selv. Så henvisningen til Intel VT-d er nok ikke annet som «dumbed down marketing speech» for et mer generisk krav til «Input–output memory management unit — IOMMU», som jo Intel VT-d er et eksempel på.

 

AMD har eksempelvis sin AMD-Vi 'teknologi' som gjør samme sak som Intel VT-d. Dessverre kjenner jeg ikke til noen IOMMU i ARM verdenen[‡]. Foreløpig. Den slags står ikke øverst på ønskelista når der knappest finnes noen ARM 'hovedkort' med PCIe busslotter til generell bruk. I beste fall finner du en M.2 slott. Det er i hvert fall hva jeg designer. Skjønt jeg laget da et ARM basert PCIe innstikkskort., eller PCIe slave/device om man vil. Men som igjen bare betyr at det er Intel PC som må 'passe seg' og anvende IOMMU i sin omgang med mitt ARM baserte innstikkskort. 

 

[‡] Note to self: ARM har ikke IO-space, bare Memory-space. Herunder MMU. Undersøk om PCIe Root Complex på ARM faktisk tillater PCIe siden aksessere kontrollregisterene til DMA kontrolleren(e,) på sin side vendt innover mot de ulike ARM Advanced Microcontroller Bus Architecture (AMBA) periferibussene… Eller gis tilgang på annen minne-mappet periferi overhode.

Endret 12. juli 2020 av 1P4XZQB7

[HKS]

On 7/12/2020 at 8:25 AM, 1P4XZQB7 said:

Dessverre kjenner jeg ikke til noen IOMMU i ARM verdenen[‡]. Foreløpig. Den slags står ikke øverst på ønskelista når der knappest finnes noen ARM 'hovedkort' med PCIe busslotter til generell bruk. I beste fall finner du en M.2 slott. Det er i hvert fall hva jeg designer. Skjønt jeg laget da et ARM basert PCIe innstikkskort., eller PCIe slave/device om man vil. Men som igjen bare betyr at det er Intel PC som må 'passe seg' og anvende IOMMU i sin omgang med mitt ARM baserte innstikkskort. 

 

[‡] Note to self: ARM har ikke IO-space, bare Memory-space. Herunder MMU. Undersøk om PCIe Root Complex på ARM faktisk tillater PCIe siden aksessere kontrollregisterene til DMA kontrolleren(e,) på sin side vendt innover mot de ulike ARM Advanced Microcontroller Bus Architecture (AMBA) periferibussene… Eller gis tilgang på annen minne-mappet periferi overhode.

I ARM-verden kalles det ofte for SMMU, ikke IOMMU.

Det er tog valgfritt på ARM om du ønsker å ha koherens for IO-enheter som for eksempel er på en PCIe-bus. Ta for eksmpel Tegra X1 og X2 fra Nvidia, disse har ikke støtte for koherens på PCIe-enheter,  en Tegra Xavier har støtte for dette. De fleste nyere ARM SoC som brukes i HPC og i servere som jeg kjenner til (f. eks Kunpeng 920 eller ThunderX2) støtter IO-koherens.

Apple som er en bidragsyter til Thunderbolt har forresten også annonsert at demmes nye custom-ARM prosessorer kommer til å støtte Thunderbolt 4.

[1P4XZQB7]

HKS skrev (22 timer siden):

I ARM-verden kalles det ofte for SMMU, ikke IOMMU.

Jau, den saken var jo snublende nærliggende. Men SMMU er øyensynlig ikke en integrert del av den mer grunnleggende «Armv8 / Armv8-A Architecture Profile,» så du får ha meg unnskyldt min ignorans. Den saken sorterer snarere under HPC tilleggene. ARMv8 referansemanualen omtaler på sin side bare MMU som en integrert del av «The AArch64 Virtual Memory System Architecture,» i sin tur dypt begravet under henvisninger til cache coherence problematikk. Lykkeligvis «Noen Andres Problem™,» nærmere bestemt utviklerne operativsystem. Jeg designer maskinvare. 

 

Vil likevel påpeke at SMMU synest være langt mer som den tradisjonelle fortolkning av IOMMU. SMMU synest være en sentral del av «Arm CoreLink Interconnect,» som på sin side synest være «AMBA/AXI» på steroider. Korriger meg om jeg fabler, men på et mer grunnleggende nivå ser CoreLink ut til å være et system for [Arm] MultiMaster(-Prosessor) interconnect, der MMU-600 System Memory Management Unit opererer med hele tre stadier av minnemapping (og påfølgende konsekvenser for cache coherence,) til hjelp for en sentralisert Hypevisor som på sin side kontrollerer de ulike virtualiserte operativsystem kjørende på de ulike kjernene rundt omkring. En tilhørende GIC-600 Generic Interrupt Controller synes dertil på egen hånd være i stand til å rute interrupt til korrekt virtualisert klientoperativsystem. Og der inter-prosessor kommunikasjon tydeligvis foregår over NIC-450 CoreLink Network Interconnect. Alt sammen ganske fjernt fra min hverdag…

 

 

Men den saken som traff meg under beltestedet er at også PCI-SIG tydeligvis har standarisert hvordan slik IOMMU skal se ut fra PCI Express siden av saken. Uten at jeg har fått det med meg. Nærmere bestemt «PCIe Address Translation Services» og ytterligere «Process Address Space ID (PASID)» for tagging av mottakende virtualisert operativsystem. Noe som tillater PCIe EndPoints å være klar over og dernest delta i den resulterende IOMMU minnemappingen. Med det formål å unngå unødige ´TLB misses,´ ved å sende DMA data til riktig fysisk adresse først som sist. Men da fortsatt under et årvåkent øye fra IOMMU. 

 

Og siden Thunderbolt ikke er stort annet som PCIe pluss Plug'n Play [Hotswap] tjenester, kan vi ganske enkelt avrunde spørsmålet det hele startet med — hva Intel faktisk har spesifisert med hensyn på Thunderbolt sikkerhet — ved å konkludere at Intel må ha spesifisert «PCIe Address Translation Services» nå skal benyttes i omgang med Thunderbolt. Altså ikke Intel VT-d direkte, men der dette 'PCIe ATL' kravet i sin tur vil medføre at Intel VT-d må benyttes på Intel platform, at AMD-Vi må benyttes på AMD platform og at SMMU må benyttes på Arm platform, osv. 

 

[1P4XZQB7]

1P4XZQB7 skrev (På 14.7.2020 den 13.39):

Og siden Thunderbolt ikke er stort annet som PCIe pluss Plug'n Play [Hotswap] tjenester, kan vi ganske enkelt avrunde spørsmålet det hele startet med — hva Intel faktisk har spesifisert med hensyn på Thunderbolt sikkerhet — ved å konkludere at Intel må ha spesifisert «PCIe Address Translation Services» nå skal benyttes i omgang med Thunderbolt.

Stryk siste melding. Det viser seg at problemet snarere er at nettopp «PCIe Address Translation Services» DMA akseleratoren har sikkerhetshull. Altså at PCIe ATS/ATC protokollen er defekt, alternativt at Intel sin håndtering av saken i sin IOMMU implementasjon er defekt. Alternativt at gjeldende operativsystem ikke håndterer IOMMU korrekt. Orker ikke finne ut hva. La meg i stedet sitere doktoravhandlingen til 'Colin Lewis Rothwell' med tittelen «EXPLOITATION FROM MALICIOUS PCI EXPRESS PERIPHERALS» (Lett korrigert for dårlig engelsk.) 

 

« We discovered a number of vulnerabilities in the PCIe protocol itself, and with the way that the defence mechanisms it provides are used by modern OSes. The principal defence mechanism provided is the Input/Output Memory Management Unit [IOMMU]. This device remaps address space visible to peripherals in 4KiB chunks, and prevents access to areas of physical address space that the peripheral should not be able to access.

 

We found that, contrary to belief in the security community, the IOMMUs in modern systems are not designed to protect against attacks from malicious peripherals, but to allow virtual machines direct access to real hardware.

 

We discovered that use of the IOMMU is patchy even in modern operating systems.

• Windows effectively does not use the IOMMU at all;
• macOS opens windows [physical memory ranges] that are shared by all devices;
• Linux and FreeBSD map windows into host memory separately for each device, but only if poorly documented boot flags are used. »

 

Som et resultat av disse hullene har Linux utviklerne [enn så lenge] stengt ned hele PCIe ATS/ATC DMA akseleratoren for Thunderbolt enheter. Dermed må all DMA fra slike enheter passere i gjennom full IOMMU minnemapping, med påfølgende ytelsestap. 

• Linux Kernel e-mail: «IOMMU/VT-d: Do not enable ATS for external devices»

…og med det slutter jeg å høre etter. Har ingen Thunderbolt enheter og gir egentlig blaffen. Utover en viss profesjonell interesse av å vite hva saken reelt handler om på et maskinvaredståsted, forbi hva den kulørte fagpressen evner rapportere. 

Endret 21. juli 2020 av 1P4XZQB7