FAQ: update the entry related to HDD firmware

IRC logs are unprofessional. Tweak the entry so that the information is
presented in a proper paragraph.

1 files changed, 24 insertions, 22 deletions

diff --git a/site/faq/index.php b/site/faq/index.php
index 0c8fdb0..b525eb0 100644
--- a/site/faq/index.php
+++ b/site/faq/index.php
@@ -837,33 +837,35 @@
 						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>
-						&lt;CareBear\&gt; francis7 : so FIS type 39h is "DMA Activate FIS - Device to Host", which sounds interesting<br/>
-						&lt;CareBear\&gt; &quot;transfer of data from the host to the device&quot;<br/>
-						&lt;CareBear\&gt; &quot;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.&quot;<br/>
-						&lt;CareBear\&gt; FIS is a protocol unit, frame information structure<br/>
-						&lt;CareBear\&gt; 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/>
-						&lt;CareBear\&gt; oh, but the drive can also send DMA Setup<br/>
-						&lt;CareBear\&gt;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/>
-						&lt;CareBear\&gt; &quot;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.&quot; translation: if the problem isn't already there it will be shortly<br/>
-						&lt;CareBear\&gt; &quot;Upon receiving a DMA Setup, the receiver of the FIS shall validate the received DMA Setup request&quot; - ie. the host is supposed to validate, but hey, maybe there's a bug there..<br/>
-						&lt;CareBear\&gt; &quot;The specific implementation of the buffer identifier and buffer/address validation is not specified.&quot; - so noone will actually bother<br/>
-						&lt;Basstard`&gt; &quot;the receiver of the FIS&quot;<br/>
-						&lt;CareBear\&gt; in the case we're considering that's the host controller hardware in the chipset and/or the kernel driver<br/>
-						&lt;CareBear\&gt; most likely kernel driver<br/>
-						&lt;CareBear\&gt; francis7 : all SATA devices have flash-upgradeable firmware<br/>
-						That last part is important. The firmware can be upgraded from the OS.<br/>
-						&lt;CareBear\&gt; the harddrive is a nice computer-in-the-computer because it also has persistent storage<br/>
-						Regarding USB:<br/>
-						&lt;CareBear\&gt; 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/>
-						&lt;CareBear\&gt; 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>
+                        According to those linked documents, FIS type 39h is <em>&quot;DMA Activate FIS - Device to Host&quot;</em>. It mentions
+                        <em>&quot;transfer of data from the host to the device, and goes on to say:
+                        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.&quot;</em>
+                        FIS is a protocol unit (Frame Information Structure). Based on this, it seems that a drive can tell the host controller that it would like
+                        for DMA to happen, but unless the host software has already or will in the future set up this DMA transfer then nothing happens.
+                        <strong>A drive can also send DMA Setup</strong>.
+                        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.
+                        The document goes on to say <em>&quot;Upon receiving a DMA Setup, the receiver of the FIS shall validate the received DMA Setup request.&quot;</em> - 
+                        in other words, the host is supposed to validate; but maybe there's a bug there.
+                        The document goes on to say <em>&quot;The specific implementation of the buffer identifier and buffer/address validation is not specified&quot;</em> - so noone will actually bother.
+                        <em>&quot;the receiver of the FIS&quot;</em> - in the case we're considering, that's the host controller hardware in the chipset and/or the kernel driver (most
+                        likely the kernel driver). All SATA devices have flash-upgradeable firmware, which can usually be updated by running software in the operating system (e.g. GNU/Linux);
+                        <strong>malicious software running as root could update this firmware, or the firmware could already be malicious</strong>.
+                        Your HDD or SSD is the perfect place for a malicious adversary to install malware, because it's a persistent storage device as well as a computer.
+                    </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 many HDDs (a few high-end ones
 						can use more bandwidth than USB 2.0 is capable of),
 						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>
+                        Use of USB is also not an absolute guarantee of safety, so do beware. The attack surface becomes much smaller, but a malicious drive could still
+                        attempt a &quot;fuzzing&quot; attack (e.g. sending malformed USB descriptors, which is how the tyrant DRM on the Playstation 3 was broken, so
+                        that users could run their own operating system and run unsigned code).
+                        (you're probably safe, unless there's a security flaw in the USB library/driver that your OS uses. USB is generally considered one of the
+                        safest protocols, precisely because USB devices have no DMA)
+                    </p>
 					<p>
 						Other links:
 					</p>