Hello everyone, I have been looking into some of our lower-level hardware interfaces, specifically auditing the AHCI driver (drivers/ata/ahci.c) through a zero-trust hardware lens. With the rise of malicious peripherals and PCIe-level attacks, I am concerned about the level of implicit trust placed in MMIO responses within this driver.
I wanted to bring up a few specific architectural vulnerabilities and see if anyone on the list is also an active kernel developer who might have insight or interest in this area. Here are the primary flaws I have mapped out: 1. Unclamped MMIO Reads (Untrusted Port Maps) The driver allocates resources based on the number of ports the hardware claims via `hpriv->cap` and `hpriv->port_map`. There is no strict clamping to the AHCI architectural maximum (32 ports) before allocation. A malformed response could force oversized kernel memory allocations or out-of-bounds reads. 2. Infinite Interrupt Loops (State Machine DoS) In handlers like `ahci_thunderx_irq_handler`, the driver loops as long as the hardware asserts a pending interrupt. Without an iteration bound, a hostile or malfunctioning controller can trap the kernel in an infinite spinlock loop, starving the CPU and causing a hard lockup. 3. Weak DMA/IOMMU Enforcement While DMA masks are configured, there is a reliance on the hardware acting in good faith. If IOMMU policies are not strictly enforced to restrict the controller to specific bounce buffers, a compromised device could use Direct Memory Access to rewrite live kernel memory from the outside in. I believe we should be architecting defenses that treat the hardware boundary as entirely hostile, integrating mitigations like `array_index_nospec` for bounds checking and enforcing strict interrupt throttling. Are there any kernel developers here who have been looking at similar hardening efforts for libata or the AHCI subsystem? Best regards,
