summaryrefslogtreecommitdiff
path: root/docs/howtos/dock.html
blob: ef62e83d96afb879a100c205dab9929af43a1d27 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
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>