20231111_Zzb_N7TTh_8_1699728021.md

Secure Data Transfer Model Overview

Background Knowledge

• The session covers the basics of the Input/Output Memory Management Unit (IOMMU) and virtual IOMMU, and why there is a need for a new secure data transfer model.
• The IOMMU is a hardware unit that handles I/O translation and device isolation. A virtual IOMMU acts like a real one.

Current Data Transfer Model and Its Limitations

• The current data transfer model involves exposing the entire guest memory address space to the driver, which could potentially be exploited by malicious programs.
• This is why there is a need for a new secure data transfer model.

New Secure Data Transfer Model

• The new secure data transfer model introduces an IOMMU to the guest.
• This effectively switches the guest physical address to an I/O virtual address, which can be achieved using DMA API in the guest kernel.
• However, this model introduces a new concern - the increase in overhead from the QEMU, which could impact system performance.

Optimizing the New Secure Data Transfer Model

• A further optimization is introduced to address the performance impact with the Address Translation Services (ATS).
• ATS is a PCI SIG specification that allows a specific PCIe device to synchronize its IOTLB entries with IOMMU, enabling direct memory access without interference from IOMMU.

x86 System Interrupts

• Interrupt remapping is also covered, which provides protection against malicious interrupts.
• Two types of interrupts are used in x86 systems, line-based interrupts and signal-based interrupts.

Interrupt Remapping

• Interrupt remapping involves interrupt remapping hardware (IRH), which is able to trap and report malicious interrupts.
• This is achieved by supporting two types of interrupts and emulating certain chipsets.

Making Interrupt Remapping Faster

• Making interrupt remapping faster involves supporting the Virtual Advanced Programmable Interrupt Controller (vAPIC) and Virtual I/O APIC (vIOAPIC).
• This is achieved by having an interrupt cache inside the kernel.# Overview

Implementation of Internet Interrupt Remapping for V I Pick

• The translation is slightly different from the email related one.
• For this, we translate on the fly. For example, if there is an interrupt generated, we translate and deliver.
• For the VA pick support, we cache the translated result into the GI side routing table which is quicker.
• We do the translation beforehand, so when the interrupt is triggered, we do not need to translate it at all.

Implementation of Split Microchip Support

• The full colonel microchip support cannot be supported because we cannot trap it in Kumu.
• However, split is quite okay for us because for one thing it is fast and for the other thing it is safer.

Implementation of IFD Support

• This is done based on GI side routing table.
• We set up routing table first, set up our QFT and everything works.
• Q is responsible to set up everything, set up the V host back-end, set up GSI routing table and insert every MSN messages.
• When the interrupt comes, we just got an event which is an interrupt to be host.

Performance Numbers

• The whole work is for deep DK and the BTK only, mostly for static DMA mapping DB decay trees DMA addresses.
• For TBD k case, our work works quite well. We get safety and we drop 5% performance.
• For dynamic DMA mapping, the performance is dramatically worse.
• Most of the patches emerged upstream except recent ones.

Future Work

• There are still lots of works to be done.
• For dynamic DMA mapping, the performance needs to be improved.
• For the full colonel microchip support, a solution to trap it in Kumu needs to be found.