On Sat, Oct 20, 2018 at 02:44:29AM +0000, Joseph Mayer wrote: > > Last iteration from me on this one. > > Why is this not a problem on some other architectures?
It is a problem, it's just that other archs don't have an iommu like sparc64. > I'd have thought DMA and hardware being assigned transitory addresses > (from memory allocator or other OS subsystem or driver) mostly is a > lower level phenomenon and memcpy normally applies on higher levels, > isn't it so - for networking for instance, mbuf's take over soon above > the driver level. Does OpenBSD have a pool of to-be-mbufs and it asks > network drivers to write received ethernet frames directly to them, and > similarly transmit ethernet frames directly from mbuf:s? Hrm. There's three views of memory you need to keep in mind here. Memory has a physical address which gets mapped to virtual addresses that the kernel and programs see. Finally, there's the DMA address, which is the address devices use to access physical memory. On most archs the physical and dma addresses are the same thing. On archs with an IOMMU or similar, the dma address can be virtual, just like the kernel addresses are virtual. When you allocate an mbuf, you're getting a chunk of physical memory that is mapped into the kernel virtual address space. For a device to do something with it, the kernel has the bus_dma api that figures out the dma address of the physical memory behind the kernel virtual address. On sparc64, that figuring out involves finding the physical address on the memory, then allocating and filling TTEs. On amd64, it just has to get the physical address of the kva and the device can use it directly. > What potentially or clearly sensitive memory would passthru expose, > driver-owned structures only or all memory? Passthru menas a device can access all the physical memory in a computer. So everything.
