Commit | Line | Data |
---|---|---|
dec6224b AS |
1 | .. _embargoed_hardware_issues: |
2 | ||
ddaedbbe TG |
3 | Embargoed hardware issues |
4 | ========================= | |
5 | ||
6 | Scope | |
7 | ----- | |
8 | ||
9 | Hardware issues which result in security problems are a different category | |
f56f791f | 10 | of security bugs than pure software bugs which only affect the Linux |
ddaedbbe TG |
11 | kernel. |
12 | ||
13 | Hardware issues like Meltdown, Spectre, L1TF etc. must be treated | |
14 | differently because they usually affect all Operating Systems ("OS") and | |
15 | therefore need coordination across different OS vendors, distributions, | |
16 | hardware vendors and other parties. For some of the issues, software | |
17 | mitigations can depend on microcode or firmware updates, which need further | |
18 | coordination. | |
19 | ||
20 | .. _Contact: | |
21 | ||
22 | Contact | |
23 | ------- | |
24 | ||
25 | The Linux kernel hardware security team is separate from the regular Linux | |
26 | kernel security team. | |
27 | ||
28 | The team only handles the coordination of embargoed hardware security | |
29 | issues. Reports of pure software security bugs in the Linux kernel are not | |
30 | handled by this team and the reporter will be guided to contact the regular | |
31 | Linux kernel security team (:ref:`Documentation/admin-guide/ | |
32 | <securitybugs>`) instead. | |
33 | ||
34 | The team can be contacted by email at <hardware-security@kernel.org>. This | |
35 | is a private list of security officers who will help you to coordinate an | |
36 | issue according to our documented process. | |
37 | ||
38 | The list is encrypted and email to the list can be sent by either PGP or | |
39 | S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME | |
40 | certificate. The list's PGP key and S/MIME certificate are available from | |
ab229d62 KR |
41 | the following URLs: |
42 | ||
43 | - PGP: https://www.kernel.org/static/files/hardware-security.asc | |
44 | - S/MIME: https://www.kernel.org/static/files/hardware-security.crt | |
ddaedbbe TG |
45 | |
46 | While hardware security issues are often handled by the affected hardware | |
47 | vendor, we welcome contact from researchers or individuals who have | |
48 | identified a potential hardware flaw. | |
49 | ||
50 | Hardware security officers | |
51 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
52 | ||
53 | The current team of hardware security officers: | |
54 | ||
55 | - Linus Torvalds (Linux Foundation Fellow) | |
56 | - Greg Kroah-Hartman (Linux Foundation Fellow) | |
57 | - Thomas Gleixner (Linux Foundation Fellow) | |
58 | ||
59 | Operation of mailing-lists | |
60 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
61 | ||
62 | The encrypted mailing-lists which are used in our process are hosted on | |
ab229d62 KR |
63 | Linux Foundation's IT infrastructure. By providing this service, members |
64 | of Linux Foundation's IT operations personnel technically have the | |
65 | ability to access the embargoed information, but are obliged to | |
66 | confidentiality by their employment contract. Linux Foundation IT | |
67 | personnel are also responsible for operating and managing the rest of | |
68 | kernel.org infrastructure. | |
69 | ||
70 | The Linux Foundation's current director of IT Project infrastructure is | |
ddaedbbe TG |
71 | Konstantin Ryabitsev. |
72 | ||
73 | ||
74 | Non-disclosure agreements | |
75 | ------------------------- | |
76 | ||
77 | The Linux kernel hardware security team is not a formal body and therefore | |
78 | unable to enter into any non-disclosure agreements. The kernel community | |
79 | is aware of the sensitive nature of such issues and offers a Memorandum of | |
80 | Understanding instead. | |
81 | ||
82 | ||
83 | Memorandum of Understanding | |
84 | --------------------------- | |
85 | ||
86 | The Linux kernel community has a deep understanding of the requirement to | |
87 | keep hardware security issues under embargo for coordination between | |
88 | different OS vendors, distributors, hardware vendors and other parties. | |
89 | ||
90 | The Linux kernel community has successfully handled hardware security | |
91 | issues in the past and has the necessary mechanisms in place to allow | |
92 | community compliant development under embargo restrictions. | |
93 | ||
94 | The Linux kernel community has a dedicated hardware security team for | |
95 | initial contact, which oversees the process of handling such issues under | |
96 | embargo rules. | |
97 | ||
98 | The hardware security team identifies the developers (domain experts) who | |
99 | will form the initial response team for a particular issue. The initial | |
100 | response team can bring in further developers (domain experts) to address | |
101 | the issue in the best technical way. | |
102 | ||
103 | All involved developers pledge to adhere to the embargo rules and to keep | |
104 | the received information confidential. Violation of the pledge will lead to | |
105 | immediate exclusion from the current issue and removal from all related | |
106 | mailing-lists. In addition, the hardware security team will also exclude | |
107 | the offender from future issues. The impact of this consequence is a highly | |
108 | effective deterrent in our community. In case a violation happens the | |
109 | hardware security team will inform the involved parties immediately. If you | |
110 | or anyone becomes aware of a potential violation, please report it | |
111 | immediately to the Hardware security officers. | |
112 | ||
113 | ||
114 | Process | |
115 | ^^^^^^^ | |
116 | ||
117 | Due to the globally distributed nature of Linux kernel development, | |
118 | face-to-face meetings are almost impossible to address hardware security | |
119 | issues. Phone conferences are hard to coordinate due to time zones and | |
120 | other factors and should be only used when absolutely necessary. Encrypted | |
121 | email has been proven to be the most effective and secure communication | |
122 | method for these types of issues. | |
123 | ||
124 | Start of Disclosure | |
125 | """"""""""""""""""" | |
126 | ||
127 | Disclosure starts by contacting the Linux kernel hardware security team by | |
128 | email. This initial contact should contain a description of the problem and | |
129 | a list of any known affected hardware. If your organization builds or | |
130 | distributes the affected hardware, we encourage you to also consider what | |
131 | other hardware could be affected. | |
132 | ||
133 | The hardware security team will provide an incident-specific encrypted | |
134 | mailing-list which will be used for initial discussion with the reporter, | |
135 | further disclosure and coordination. | |
136 | ||
137 | The hardware security team will provide the disclosing party a list of | |
138 | developers (domain experts) who should be informed initially about the | |
139 | issue after confirming with the developers that they will adhere to this | |
140 | Memorandum of Understanding and the documented process. These developers | |
141 | form the initial response team and will be responsible for handling the | |
142 | issue after initial contact. The hardware security team is supporting the | |
143 | response team, but is not necessarily involved in the mitigation | |
144 | development process. | |
145 | ||
146 | While individual developers might be covered by a non-disclosure agreement | |
147 | via their employer, they cannot enter individual non-disclosure agreements | |
148 | in their role as Linux kernel developers. They will, however, agree to | |
149 | adhere to this documented process and the Memorandum of Understanding. | |
150 | ||
dc925a36 TG |
151 | The disclosing party should provide a list of contacts for all other |
152 | entities who have already been, or should be, informed about the issue. | |
153 | This serves several purposes: | |
154 | ||
155 | - The list of disclosed entities allows communication accross the | |
156 | industry, e.g. other OS vendors, HW vendors, etc. | |
157 | ||
158 | - The disclosed entities can be contacted to name experts who should | |
159 | participate in the mitigation development. | |
160 | ||
161 | - If an expert which is required to handle an issue is employed by an | |
162 | listed entity or member of an listed entity, then the response teams can | |
163 | request the disclosure of that expert from that entity. This ensures | |
164 | that the expert is also part of the entity's response team. | |
ddaedbbe TG |
165 | |
166 | Disclosure | |
167 | """""""""" | |
168 | ||
169 | The disclosing party provides detailed information to the initial response | |
170 | team via the specific encrypted mailing-list. | |
171 | ||
172 | From our experience the technical documentation of these issues is usually | |
173 | a sufficient starting point and further technical clarification is best | |
174 | done via email. | |
175 | ||
176 | Mitigation development | |
177 | """""""""""""""""""""" | |
178 | ||
179 | The initial response team sets up an encrypted mailing-list or repurposes | |
dc925a36 | 180 | an existing one if appropriate. |
ddaedbbe TG |
181 | |
182 | Using a mailing-list is close to the normal Linux development process and | |
183 | has been successfully used in developing mitigations for various hardware | |
184 | security issues in the past. | |
185 | ||
186 | The mailing-list operates in the same way as normal Linux development. | |
187 | Patches are posted, discussed and reviewed and if agreed on applied to a | |
188 | non-public git repository which is only accessible to the participating | |
189 | developers via a secure connection. The repository contains the main | |
190 | development branch against the mainline kernel and backport branches for | |
191 | stable kernel versions as necessary. | |
192 | ||
193 | The initial response team will identify further experts from the Linux | |
dc925a36 TG |
194 | kernel developer community as needed. Bringing in experts can happen at any |
195 | time of the development process and needs to be handled in a timely manner. | |
196 | ||
197 | If an expert is employed by or member of an entity on the disclosure list | |
198 | provided by the disclosing party, then participation will be requested from | |
199 | the relevant entity. | |
200 | ||
201 | If not, then the disclosing party will be informed about the experts | |
202 | participation. The experts are covered by the Memorandum of Understanding | |
203 | and the disclosing party is requested to acknowledge the participation. In | |
204 | case that the disclosing party has a compelling reason to object, then this | |
205 | objection has to be raised within five work days and resolved with the | |
206 | incident team immediately. If the disclosing party does not react within | |
207 | five work days this is taken as silent acknowledgement. | |
208 | ||
209 | After acknowledgement or resolution of an objection the expert is disclosed | |
210 | by the incident team and brought into the development process. | |
211 | ||
ddaedbbe TG |
212 | |
213 | Coordinated release | |
214 | """"""""""""""""""" | |
215 | ||
216 | The involved parties will negotiate the date and time where the embargo | |
217 | ends. At that point the prepared mitigations are integrated into the | |
218 | relevant kernel trees and published. | |
219 | ||
220 | While we understand that hardware security issues need coordinated embargo | |
221 | time, the embargo time should be constrained to the minimum time which is | |
222 | required for all involved parties to develop, test and prepare the | |
223 | mitigations. Extending embargo time artificially to meet conference talk | |
224 | dates or other non-technical reasons is creating more work and burden for | |
225 | the involved developers and response teams as the patches need to be kept | |
226 | up to date in order to follow the ongoing upstream kernel development, | |
227 | which might create conflicting changes. | |
228 | ||
229 | CVE assignment | |
230 | """""""""""""" | |
231 | ||
232 | Neither the hardware security team nor the initial response team assign | |
233 | CVEs, nor are CVEs required for the development process. If CVEs are | |
234 | provided by the disclosing party they can be used for documentation | |
235 | purposes. | |
236 | ||
237 | Process ambassadors | |
238 | ------------------- | |
239 | ||
240 | For assistance with this process we have established ambassadors in various | |
241 | organizations, who can answer questions about or provide guidance on the | |
242 | reporting process and further handling. Ambassadors are not involved in the | |
243 | disclosure of a particular issue, unless requested by a response team or by | |
244 | an involved disclosed party. The current ambassadors list: | |
245 | ||
246 | ============= ======================================================== | |
ae7fce06 | 247 | ARM Grant Likely <grant.likely@arm.com> |
4a9acb6d | 248 | AMD Tom Lendacky <tom.lendacky@amd.com> |
ddaedbbe | 249 | IBM |
38c7a30a | 250 | Intel Tony Luck <tony.luck@intel.com> |
a8e0abae | 251 | Qualcomm Trilok Soni <tsoni@codeaurora.org> |
ddaedbbe | 252 | |
4bc4f812 | 253 | Microsoft James Morris <jamorris@linux.microsoft.com> |
ddaedbbe | 254 | VMware |
02e740ae | 255 | Xen Andrew Cooper <andrew.cooper3@citrix.com> |
ddaedbbe | 256 | |
3da62707 | 257 | Canonical John Johansen <john.johansen@canonical.com> |
ddaedbbe TG |
258 | Debian Ben Hutchings <ben@decadent.org.uk> |
259 | Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | |
260 | Red Hat Josh Poimboeuf <jpoimboe@redhat.com> | |
261 | SUSE Jiri Kosina <jkosina@suse.cz> | |
262 | ||
485d5b75 | 263 | Amazon |
f56f791f KC |
264 | Google Kees Cook <keescook@chromium.org> |
265 | ============= ======================================================== | |
ddaedbbe TG |
266 | |
267 | If you want your organization to be added to the ambassadors list, please | |
268 | contact the hardware security team. The nominated ambassador has to | |
269 | understand and support our process fully and is ideally well connected in | |
270 | the Linux kernel community. | |
271 | ||
272 | Encrypted mailing-lists | |
273 | ----------------------- | |
274 | ||
275 | We use encrypted mailing-lists for communication. The operating principle | |
276 | of these lists is that email sent to the list is encrypted either with the | |
277 | list's PGP key or with the list's S/MIME certificate. The mailing-list | |
278 | software decrypts the email and re-encrypts it individually for each | |
279 | subscriber with the subscriber's PGP key or S/MIME certificate. Details | |
280 | about the mailing-list software and the setup which is used to ensure the | |
281 | security of the lists and protection of the data can be found here: | |
ab229d62 | 282 | https://korg.wiki.kernel.org/userdoc/remail. |
ddaedbbe TG |
283 | |
284 | List keys | |
285 | ^^^^^^^^^ | |
286 | ||
287 | For initial contact see :ref:`Contact`. For incident specific mailing-lists | |
288 | the key and S/MIME certificate are conveyed to the subscribers by email | |
289 | sent from the specific list. | |
290 | ||
291 | Subscription to incident specific lists | |
292 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
293 | ||
294 | Subscription is handled by the response teams. Disclosed parties who want | |
295 | to participate in the communication send a list of potential subscribers to | |
296 | the response team so the response team can validate subscription requests. | |
297 | ||
298 | Each subscriber needs to send a subscription request to the response team | |
299 | by email. The email must be signed with the subscriber's PGP key or S/MIME | |
300 | certificate. If a PGP key is used, it must be available from a public key | |
301 | server and is ideally connected to the Linux kernel's PGP web of trust. See | |
302 | also: https://www.kernel.org/signature.html. | |
303 | ||
304 | The response team verifies that the subscriber request is valid and adds | |
305 | the subscriber to the list. After subscription the subscriber will receive | |
306 | email from the mailing-list which is signed either with the list's PGP key | |
307 | or the list's S/MIME certificate. The subscriber's email client can extract | |
308 | the PGP key or the S/MIME certificate from the signature so the subscriber | |
309 | can send encrypted email to the list. | |
310 |