1 .. _embargoed_hardware_issues:
2
3 Embargoed hardware issues
4 =========================
5
6 Scope
7 -----
8
9 Hardware issues which result in security probl
10 of security bugs than pure software bugs which
11 kernel.
12
13 Hardware issues like Meltdown, Spectre, L1TF e
14 differently because they usually affect all Op
15 therefore need coordination across different O
16 silicon vendors, hardware integrators, and oth
17 issues, software mitigations can depend on mic
18 which need further coordination.
19
20 .. _Contact:
21
22 Contact
23 -------
24
25 The Linux kernel hardware security team is sep
26 kernel security team.
27
28 The team only handles developing fixes for emb
29 issues. Reports of pure software security bugs
30 handled by this team and the reporter will be
31 Linux kernel security team (:ref:`Documentatio
32 <securitybugs>`) instead.
33
34 The team can be contacted by email at <hardware
35 is a private list of security officers who wil
36 according to our documented process.
37
38 The list is encrypted and email to the list ca
39 S/MIME encrypted and must be signed with the r
40 certificate. The list's PGP key and S/MIME cer
41 the following URLs:
42
43 - PGP: https://www.kernel.org/static/files/h
44 - S/MIME: https://www.kernel.org/static/file
45
46 While hardware security issues are often handl
47 vendor, we welcome contact from researchers or
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 Fello
57 - Thomas Gleixner (Linux Foundation Fellow)
58
59 Operation of mailing-lists
60 ^^^^^^^^^^^^^^^^^^^^^^^^^^
61
62 The encrypted mailing-lists which are used in
63 Linux Foundation's IT infrastructure. By provi
64 of Linux Foundation's IT operations personnel
65 ability to access the embargoed information, b
66 confidentiality by their employment contract.
67 personnel are also responsible for operating a
68 kernel.org's infrastructure.
69
70 The Linux Foundation's current director of IT
71 Konstantin Ryabitsev.
72
73
74 Non-disclosure agreements
75 -------------------------
76
77 The Linux kernel hardware security team is not
78 unable to enter into any non-disclosure agreem
79 is aware of the sensitive nature of such issue
80 Understanding instead.
81
82
83 Memorandum of Understanding
84 ---------------------------
85
86 The Linux kernel community has a deep understa
87 keep hardware security issues under embargo fo
88 different OS vendors, distributors, silicon ve
89
90 The Linux kernel community has successfully ha
91 issues in the past and has the necessary mecha
92 community compliant development under embargo
93
94 The Linux kernel community has a dedicated har
95 initial contact, which oversees the process of
96 embargo rules.
97
98 The hardware security team identifies the deve
99 will form the initial response team for a part
100 response team can bring in further developers
101 the issue in the best technical way.
102
103 All involved developers pledge to adhere to th
104 the received information confidential. Violati
105 immediate exclusion from the current issue and
106 mailing lists. In addition, the hardware secur
107 the offender from future issues. The impact of
108 effective deterrent in our community. In case
109 hardware security team will inform the involve
110 or anyone else becomes aware of a potential vi
111 immediately to the Hardware security officers.
112
113
114 Process
115 ^^^^^^^
116
117 Due to the globally distributed nature of Linu
118 face-to-face meetings are almost impossible to
119 issues. Phone conferences are hard to coordin
120 other factors and should be only used when abs
121 email has been proven to be the most effective
122 method for these types of issues.
123
124 Start of Disclosure
125 """""""""""""""""""
126
127 Disclosure starts by emailing the Linux kernel
128 the Contact section above. This initial conta
129 description of the problem and a list of any k
130 your organization builds or distributes the af
131 you to also consider what other hardware could
132 party is responsible for contacting the affect
133 timely manner.
134
135 The hardware security team will provide an inc
136 mailing list which will be used for initial di
137 further disclosure, and coordination of fixes.
138
139 The hardware security team will provide the di
140 developers (domain experts) who should be info
141 issue after confirming with the developers tha
142 Memorandum of Understanding and the documented
143 form the initial response team and will be res
144 issue after initial contact. The hardware secu
145 response team, but is not necessarily involved
146 development process.
147
148 While individual developers might be covered b
149 via their employer, they cannot enter individu
150 in their role as Linux kernel developers. They
151 adhere to this documented process and the Memo
152
153 The disclosing party should provide a list of
154 entities who have already been, or should be,
155 This serves several purposes:
156
157 - The list of disclosed entities allows commu
158 industry, e.g. other OS vendors, HW vendors
159
160 - The disclosed entities can be contacted to
161 participate in the mitigation development.
162
163 - If an expert who is required to handle an i
164 entity or member of an listed entity, then
165 request the disclosure of that expert from
166 that the expert is also part of the entity'
167
168 Disclosure
169 """"""""""
170
171 The disclosing party provides detailed informa
172 team via the specific encrypted mailing-list.
173
174 From our experience, the technical documentati
175 a sufficient starting point, and further techn
176 done via email.
177
178 Mitigation development
179 """"""""""""""""""""""
180
181 The initial response team sets up an encrypted
182 an existing one if appropriate.
183
184 Using a mailing list is close to the normal Li
185 has been successfully used to develop mitigati
186 security issues in the past.
187
188 The mailing list operates in the same way as n
189 Patches are posted, discussed, and reviewed an
190 a non-public git repository which is only acce
191 developers via a secure connection. The reposi
192 development branch against the mainline kernel
193 stable kernel versions as necessary.
194
195 The initial response team will identify furthe
196 kernel developer community as needed. Any inv
197 further experts to be included, each of which
198 requirements outlined above.
199
200 Bringing in experts can happen at any time in
201 needs to be handled in a timely manner.
202
203 If an expert is employed by or a member of an
204 provided by the disclosing party, then partici
205 the relevant entity.
206
207 If not, then the disclosing party will be info
208 participation. The experts are covered by the
209 and the disclosing party is requested to ackno
210 In the case where the disclosing party has a c
211 any objection must to be raised within five wo
212 the incident team immediately. If the disclosi
213 within five working days this is taken as sile
214
215 After the incident team acknowledges or resolv
216 is disclosed and brought into the development
217
218 List participants may not communicate about th
219 private mailing list. List participants may no
220 (e.g. employer build farms, CI systems, etc) w
221
222 Early access
223 """"""""""""
224
225 The patches discussed and developed on the lis
226 to any individual who is not a member of the r
227 organization.
228
229 To allow the affected silicon vendors to work
230 industry partners on testing, validation, and
231 exception is provided:
232
233 Designated representatives of the affe
234 allowed to hand over the patches at an
235 vendor’s response team. The represen
236 response team about the handover. The
237 have and maintain their own documented
238 patches shared with their response tea
239 this policy.
240
241 The silicon vendor’s response team c
242 their industry partners and to their i
243 silicon vendor’s documented security
244 industry partners goes back to the sil
245 communicated by the silicon vendor to
246
247 The handover to the silicon vendor’s
248 responsibility or liability from the k
249 premature disclosure, which happens du
250 silicon vendor’s internal teams or i
251 vendor guarantees this release of liab
252 process.
253
254 Coordinated release
255 """""""""""""""""""
256
257 The involved parties will negotiate the date a
258 ends. At that point, the prepared mitigations
259 relevant kernel trees. There is no pre-notifi
260 mitigations are published in public and availa
261 time.
262
263 While we understand that hardware security iss
264 time, the embargo time should be constrained t
265 required for all involved parties to develop,
266 mitigations. Extending embargo time artificial
267 dates or other non-technical reasons creates m
268 involved developers and response teams as the
269 date in order to follow the ongoing upstream k
270 might create conflicting changes.
271
272 CVE assignment
273 """"""""""""""
274
275 Neither the hardware security team nor the ini
276 CVEs, nor are CVEs required for the developmen
277 provided by the disclosing party they can be u
278 purposes.
279
280 Process ambassadors
281 -------------------
282
283 For assistance with this process we have estab
284 organizations, who can answer questions about
285 reporting process and further handling. Ambass
286 disclosure of a particular issue, unless reque
287 an involved disclosed party. The current ambas
288
289 ============= ==============================
290 AMD Tom Lendacky <thomas.lendacky@a
291 Ampere Darren Hart <darren@os.ampereco
292 ARM Catalin Marinas <catalin.marina
293 IBM Power Michael Ellerman <ellerman@au.i
294 IBM Z Christian Borntraeger <borntrae
295 Intel Tony Luck <tony.luck@intel.com>
296 Qualcomm Trilok Soni <quic_tsoni@quicinc
297 RISC-V Palmer Dabbelt <palmer@dabbelt.
298 Samsung Javier González <javier.gonz@s
299
300 Microsoft James Morris <jamorris@linux.mi
301 Xen Andrew Cooper <andrew.cooper3@c
302
303 Canonical John Johansen <john.johansen@ca
304 Debian Ben Hutchings <ben@decadent.org
305 Oracle Konrad Rzeszutek Wilk <konrad.w
306 Red Hat Josh Poimboeuf <jpoimboe@redhat
307 SUSE Jiri Kosina <jkosina@suse.cz>
308
309 Google Kees Cook <keescook@chromium.or
310
311 LLVM Nick Desaulniers <ndesaulniers@
312 ============= ==============================
313
314 If you want your organization to be added to t
315 contact the hardware security team. The nomina
316 understand and support our process fully and i
317 the Linux kernel community.
318
319 Encrypted mailing-lists
320 -----------------------
321
322 We use encrypted mailing lists for communicati
323 of these lists is that email sent to the list
324 list's PGP key or with the list's S/MIME certi
325 software decrypts the email and re-encrypts it
326 subscriber with the subscriber's PGP key or S/
327 about the mailing list software and the setup
328 security of the lists and protection of the da
329 https://korg.wiki.kernel.org/userdoc/remail.
330
331 List keys
332 ^^^^^^^^^
333
334 For initial contact see the :ref:`Contact` sec
335 specific mailing lists, the key and S/MIME cer
336 subscribers by email sent from the specific li
337
338 Subscription to incident-specific lists
339 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
340
341 Subscription to incident-specific lists is han
342 Disclosed parties who want to participate in t
343 of potential experts to the response team so t
344 subscription requests.
345
346 Each subscriber needs to send a subscription r
347 by email. The email must be signed with the su
348 certificate. If a PGP key is used, it must be
349 server and is ideally connected to the Linux k
350 also: https://www.kernel.org/signature.html.
351
352 The response team verifies that the subscriber
353 the subscriber to the list. After subscription
354 email from the mailing-list which is signed ei
355 or the list's S/MIME certificate. The subscrib
356 the PGP key or the S/MIME certificate from the
357 can send encrypted email to the list.
358
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.