Bug 32362 (ATAPIbug)
Summary: | ATA Passthrough generates incorrect LBA addresses with OS ASYNC activity, Image of Bus-trace attached | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Marcus Firthview (marcus.firthview) |
Component: | Serial ATA | Assignee: | Jeff Garzik (jgarzik) |
Status: | NEW --- | ||
Severity: | blocking | CC: | alan, szg00000 |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | All | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Finisar Bus-Trace of SG tools w/System Activity |
Created attachment 52792 [details] Finisar Bus-Trace of SG tools w/System Activity Bug: Low 28 bits of LBA address to drive after DMA completion (read/write), following the interrupt to the kernel, status is read from the drive with the updated LBA address. The 28 lower bits are then transposed into the NEXT drive commands upper 28bits. Confirmed: smartmon/sgtools using a Finisar protocol analyzer. When: Only occurs when using systems whos BIOS is set into Legacy (or ATA/IDE) modes. (Does NOT occur when using AHCI bios mode). See attached image to see what occured when running SG tools to read the SMART log (command 0x2F)... It becomes very obvious that the ATA Pass-Through driver's actual data becomes over-written with the previous commands LBA address. Example: DMA-Write LBA=00000123456 ->> BUS: Cmd 0x2f, LBA=0x0000123456 Read Status: DRDY, drive LBA=0x123457 (LBA updated in HW) Device Identify LBA=0000000000 ->> BUS: Cmd 0xec, LBA=12345700000 <-- BAD/OOPS!!! (In this case, CMD 0xec ignores LBA).. However, a cleverly constructed packet could use a read/writes combined with a previously corrupted LBA address to access portions of the drive which should be considered 'restricted/confidential', thus compromising system security and potentially by-passing AV or other security products.