diff options
Diffstat (limited to 'site/faq')
| -rw-r--r-- | site/faq/index.php | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/site/faq/index.php b/site/faq/index.php index 8eb0b7e..d5eac9c 100644 --- a/site/faq/index.php +++ b/site/faq/index.php @@ -626,6 +626,36 @@ 388-414, 420-421, 427, 446-465, 492-522, 631-638) and this <a href="http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf">http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf</a> (pages 59, 67, 94, 99). </p> <p> + The following is based on discussion with Peter Stuge (CareBear\) in the coreboot IRC channel on Friday, 18 September 2015, + when investigating whether the SATA drive itself can make use of DMA. The following is based on the datasheets linked above: + </p> + <p> + <CareBear\> francis7 : so FIS type 39h is "DMA Activate FIS - Device to Host", which sounds interesting<br/> + <CareBear\> "transfer of data from the host to the device"<br/> + <CareBear\> "Upon receiving a DMA Activate, if the host adapter’s DMA controller has been programmed and armed, the host adapter shall initiate the transmission of a Data FIS and shall transmit in this FIS the data corresponding to the host memory regions indicated by the DMA controller’s context."<br/> + <CareBear\> FIS is a protocol unit, frame information structure<br/> + <CareBear\> so it seems that a drive can tell the host controller that it would like for DMA to happen, but actually unless the host software has already or will in the future set up this DMA transfer then nothing happens<br/> + <CareBear\> oh, but the drive can also send DMA Setup<br/> + <CareBear\>if a DMA Setup FIS is sent first, with the Auto-Activate bit set, then it is already set up, and the drive can initiate DMA<br/> + <CareBear\> "First party DMA is a superset capability not neccessarily supported by legacy mode devices or legacy mode device drivers but essential for accommodating future capabilities." translation: if the problem isn't already there it will be shortly<br/> + <CareBear\> "Upon receiving a DMA Setup, the receiver of the FIS shall validate the received DMA Setup request" - ie. the host is supposed to validate, but hey, maybe there's a bug there..<br/> + <CareBear\> "The specific implementation of the buffer identifier and buffer/address validation is not specified." - so noone will actually bother + <Basstard`> "the receiver of the FIS"<br/> + <CareBear\> in the case we're considering that's the host controller hardware in the chipset and/or the kernel driver<br/> + <CareBear\> most likely kernel driver<br/> + <CareBear\> francis7 : all SATA devices have flash-upgradeable firmware + That last part is important. The firmware can be upgraded from the OS.<br/> + <CareBear\> the harddrive is a nice computer-in-the-computer because it also has persistent storage + Regarding USB:<br/> + <CareBear\> then the attack surface becomes much smaller, but assuming a malicious harddrive then it can still try to get angry with the operating system<br/> + <CareBear\> a usb drive can e.g. send malformed USB descriptors (how the PS3 was broken)<br/> + (he's talking about so-called 'fuzzing' attacks) + </p> + <p> + Based on this, it's safe to say that use of USB instead of SATA is advisable if security is a concern. USB 2.0 has plenty of bandwidth for HDDs, + but for SSDs it might be problematic (unless you're using USB 3.0, which is not yet usable in freedom. See <a href="#firmware-usbhost">#firmware-usbhost</a>). + </p> + <p> <a href="#pagetop">Back to top of page</a> </p> |