From 8466ad2d70683856bcc07e8f305f66f55b1c701a Mon Sep 17 00:00:00 2001
From: Francis Rowe <info@gluglug.org.uk>
Date: Fri, 10 Oct 2014 19:26:05 -0400
Subject: Documentation: notes about DMA and the docking station (X60/T60)

---
(limited to 'docs/howtos/dock.html')

diff --git a/docs/howtos/dock.html b/docs/howtos/dock.html
new file mode 100644
index 0000000..ef62e83
--- /dev/null
+++ b/docs/howtos/dock.html
@@ -0,0 +1,163 @@
+<!DOCTYPE html>
+<html>
+<head>
+	<meta charset="utf-8">
+	<meta name="viewport" content="width=device-width, initial-scale=1">
+
+	<style type="text/css">
+		body {
+			background:#fff;
+			color:#000;
+			font-family:sans-serif;
+			font-size:1em;
+		}
+		div.important {
+			background-color:#ccc;
+		}
+	</style>
+
+	<title>Notes about DMA and the docking station (X60/T60)</title>
+</head>
+
+<body>
+	<header>
+		<h1>Notes about DMA and the docking station (X60/T60)</h1>
+		<aside>Or <a href="../index.html">back to main index</a></aside>
+	</header>
+
+<pre>
+
+Use case:
+---------
+Usually when people do full disk encryption, it's not really full disk,
+instead they still have a /boot in clear.
+
+So an evil maid attack can still be done, in two passes:
+1) Clone the hdd, Infect the initramfs or the kernel.
+2) Wait for the user to enter its password, recover the password,
+luksOpen the hdd image.
+
+I wanted a real full-disk encryption so I've put grub in flash and I
+have the following: The HDD has a LUKS rootfs(containing /boot) on an
+lvm partition, so no partition is in clear.
+
+So when the computer boots it executes coreboot, then grub as a payload.
+Grub then opens the LUKS partition and loads the kernel and initramfs
+from there.
+
+To prevent hardware level tempering(like reflashing), I used nail
+polish with a lot of gilder, that acts like a seal. Then a high
+resolution picture of it is taken, to be able to tell the difference.
+
+The problem:
+------------
+But then comes the docking port issue: Some LPC pins are exported
+there, such as the CLKRUN and LDRQ#.
+
+LDRQ# is "Encoded DMA/Bus Master Request": "Only needed by
+peripherals that need DMA or bus mastering. Requires an
+individual signal per peripheral. Peripherals may not share
+an LDRQ# signal."
+
+So now DMA access is possible trough the dock connector.
+So I want to be able to turn that off.
+
+If I got it right, the X60 has 2 superio, one is in the dock, and the
+other one is in the laptop, so we have:
+                            ________________
+ _________________         |                |
+|                 |        | Dock connector:|
+|Dock: NSC pc87982|<--LPC--->D_LPC_DREQ0    |
+|_________________|        |_______^________|
+                                   |
+                                   |
+                                   |
+                                   |
+                ___________________|____
+               |                   v    |
+               | SuperIO:        DLDRQ# |
+               | NSC pc87382     LDRQ#  |
+               |___________________^____|
+                                   |
+                                   |
+                                   |
+                                   |
+                ___________________|___
+               |                   v   |
+               | Southbridge:    LDRQ0 |
+               | ICH7                  |
+               |_______________________|
+
+
+The code:
+---------
+Now if I look at the existing code, there is some superio drivers, like
+pc87382 in src/superio/nsc, the code is very small. 
+The only interesting part is the pnp_info pnp_dev_info struct.
+
+Now if I look inside src/mainboard/lenovo/x60 there is some more
+complete dock driver:
+
+Inside dock.c I see some dock_connect and dock_disconnect functions.
+
+Such functions are called during the initialisation (romstage.c) and
+from the x60's SMI handler (smihandler.c).
+
+Questions:
+----------
+1) Would the following be sufficent to prevent DMA access from the
+outside:
+&gt; int dock_connect(void)
+&gt; {
+&gt;          int timeout = 1000;
+&gt; +        int val;
+&gt; +        
+&gt; +        if (get_option(&val, "dock") != CB_SUCCESS)
+&gt; +                val = 1;
+&gt; +        if (val == 0)
+&gt; +                return 0;
+&gt;          [...]
+&gt; }
+>
+&gt; void dock_disconnect(void) {
+&gt; +        if (dock_present())
+&gt; +                return;
+&gt;          [...]
+&gt; }
+2) Would an nvram option be ok for that? Should a Kconfig option be
+added too?
+
+&gt; config DOCK_AUTODETECT
+&gt;         bool "Autodetect"
+&gt;         help
+&gt;           The dock is autodetected. If unsure select this option.
+>
+&gt; config DOCK_DISABLED
+&gt;         bool "Disabled"
+&gt;         help
+&gt;           The dock is always disabled.
+>
+&gt; config DOCK_NVRAM_ENABLE
+&gt;         bool "Nvram"
+&gt;         help
+&gt;           The dock autodetection is tried only if it is also enabled
+&gt; trough nvram.
+
+</pre>
+
+<hr/>
+
+	<p>
+		Copyright &copy; 2014 Francis Rowe &lt;info@gluglug.org.uk&gt;<br/>
+		This document is released under the Creative Commons Attribution-ShareAlike 4.0 International Public License and all future versions.
+		A copy of the license can be found at <a href="../license.txt">../license.txt</a>.
+	</p>
+
+	<p>
+		This document is distributed in the hope that it will be useful,
+		but WITHOUT ANY WARRANTY; without even the implied warranty of
+		MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See <a href="../license.txt">../license.txt</a&gt; for more information.
+	</p>
+
+</body>
+</html>
--
cgit v0.9.1