All drivers on OS X are already required to tell the operating system ahead of time that a device is about to DMA to memory. That's how that VT-d is able to configure the IOMMU hardware to allow those devices to access RAM without worrying about 64-bit address spaces. So the OS already knows precisely which pages of physical RAM should be accessible by PCIe devices using DMA. If other pages of RAM are accessible, that's a bug.
Similarly, making the Thunderbolt controller's IOMMU mappings be driven by that part of the kernel should not break any drivers at all, by definition, because PCIe devices shouldn't be issuing DMA requests except at driver-preapproved locations. So AFAIK, the only way such a fix could break any device would be if that device was trying to do something really dangerous, like reprogramming one of the PCI bus bridges, or reflashing the computer's EFI firmware....
I mean, I suppose that some drivers might be inadvertently configuring a mapping for a page of memory that also contains executable code or class instances (with function pointers), in which case fully fixing this would also require Apple to modify the IOMemoryDescriptor class to ensure that the DMA-enabled pages are whole pages owned by the descriptor, but that should still be pretty minor, and should result in only a modest amount of wired kernel memory bloat.
In the worst case, such a change might require a CPU-driven copy-on-prepare and/or copy-on-complete to work around drivers that provide their own virtual addresses for a memory descriptor that aren't page-aligned, which would cause a big performance hit for those few drivers, but I'd expect most driver developers to quickly fix those design mistakes to eliminate the performance hit. (And that's assuming this isn't done already—for some reason, I thought those buffers had to be page aligned or you'd get a panic, but I'm not seeing anything about it in the docs, so I might be remembering wrong.)