1 .. SPDX-License-Identifier: GPL-2.0 2 .. include:: ../disclaimer-sp.rst 3 4 :Original: Documentation/process/embargoed-hardware-issues.rst 5 :Translator: Avadhut Naik <avadhut.naik@amd.com> 6 7 Problemas de hardware embargados 8 ================================ 9 10 Alcance 11 ------- 12 13 Los problemas de hardware que resultan en problemas de seguridad son una 14 categoría diferente de errores de seguridad que los errores de software 15 puro que solo afectan al kernel de Linux. 16 17 Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben 18 tratarse de manera diferente porque usualmente afectan a todos los 19 sistemas operativos (“OS”) y, por lo tanto, necesitan coordinación entre 20 vendedores diferentes de OS, distribuciones, vendedores de hardware y 21 otras partes. Para algunos de los problemas, las mitigaciones de software 22 pueden depender de actualizaciones de microcódigo o firmware, los cuales 23 necesitan una coordinación adicional. 24 25 .. _Contacto: 26 27 Contacto 28 -------- 29 30 El equipo de seguridad de hardware del kernel de Linux es separado del 31 equipo regular de seguridad del kernel de Linux. 32 33 El equipo solo maneja la coordinación de los problemas de seguridad de 34 hardware embargados. Los informes de errores de seguridad de software puro 35 en el kernel de Linux no son manejados por este equipo y el "reportero" 36 (quien informa del error) será guiado a contactar el equipo de seguridad 37 del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su 38 lugar. 39 40 El equipo puede contactar por correo electrónico en 41 <hardware-security@kernel.org>. Esta es una lista privada de oficiales de 42 seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro 43 proceso documentado. 44 45 La lista esta encriptada y el correo electrónico a la lista puede ser 46 enviado por PGP o S/MIME encriptado y debe estar firmado con la llave de 47 PGP del reportero o el certificado de S/MIME. La llave de PGP y el 48 certificado de S/MIME de la lista están disponibles en las siguientes 49 URLs: 50 51 - PGP: https://www.kernel.org/static/files/hardware-security.asc 52 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt 53 54 Si bien los problemas de seguridad del hardware a menudo son manejados por 55 el vendedor de hardware afectado, damos la bienvenida al contacto de 56 investigadores o individuos que hayan identificado una posible falla de 57 hardware. 58 59 Oficiales de seguridad de hardware 60 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 61 62 El equipo actual de oficiales de seguridad de hardware: 63 64 - Linus Torvalds (Linux Foundation Fellow) 65 - Greg Kroah-Hartman (Linux Foundation Fellow) 66 - Thomas Gleixner (Linux Foundation Fellow) 67 68 Operación de listas de correo 69 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 70 71 Las listas de correo encriptadas que se utilizan en nuestro proceso están 72 alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar 73 este servicio, los miembros del personal de operaciones de IT de la 74 Fundación Linux técnicamente tienen la capacidad de acceder a la 75 información embargada, pero están obligados a la confidencialidad por su 76 contrato de trabajo. El personal de IT de la Fundación Linux también es 77 responsable para operar y administrar el resto de la infraestructura de 78 kernel.org. 79 80 El actual director de infraestructura de proyecto de IT de la Fundación 81 Linux es Konstantin Ryabitsev. 82 83 Acuerdos de no divulgación 84 -------------------------- 85 86 El equipo de seguridad de hardware del kernel de Linux no es un organismo 87 formal y, por lo tanto, no puede firmar cualquier acuerdo de no 88 divulgación. La comunidad del kernel es consciente de la naturaleza 89 delicada de tales problemas y ofrece un Memorando de Entendimiento en su 90 lugar. 91 92 Memorando de Entendimiento 93 -------------------------- 94 95 La comunidad del kernel de Linux tiene una comprensión profunda del 96 requisito de mantener los problemas de seguridad de hardware bajo embargo 97 para la coordinación entre diferentes vendedores de OS, distribuidores, 98 vendedores de hardware y otras partes. 99 100 La comunidad del kernel de Linux ha manejado con éxito los problemas de 101 seguridad del hardware en el pasado y tiene los mecanismos necesarios para 102 permitir el desarrollo compatible con la comunidad bajo restricciones de 103 embargo. 104 105 La comunidad del kernel de Linux tiene un equipo de seguridad de hardware 106 dedicado para el contacto inicial, el cual supervisa el proceso de manejo 107 de tales problemas bajo las reglas de embargo. 108 109 El equipo de seguridad de hardware identifica a los desarrolladores 110 (expertos en dominio) que formarán el equipo de respuesta inicial para un 111 problema en particular. El equipo de respuesta inicial puede involucrar 112 más desarrolladores (expertos en dominio) para abordar el problema de la 113 mejor manera técnica. 114 115 Todos los desarrolladores involucrados se comprometen a adherirse a las 116 reglas del embargo y a mantener confidencial la información recibida. La 117 violación de la promesa conducirá a la exclusión inmediata del problema 118 actual y la eliminación de todas las listas de correo relacionadas. 119 Además, el equipo de seguridad de hardware también excluirá al 120 delincuente de problemas futuros. El impacto de esta consecuencia es un 121 elemento de disuasión altamente efectivo en nuestra comunidad. En caso de 122 que ocurra una violación, el equipo de seguridad de hardware informará a 123 las partes involucradas inmediatamente. Si usted o alguien tiene 124 conocimiento de una posible violación, por favor, infórmelo inmediatamente 125 a los oficiales de seguridad de hardware. 126 127 Proceso 128 ^^^^^^^ 129 130 Debido a la naturaleza distribuida globalmente del desarrollo del kernel 131 de Linux, las reuniones cara a cara hacen imposible abordar los 132 problemas de seguridad del hardware. Las conferencias telefónicas son 133 difíciles de coordinar debido a las zonas horarias y otros factores y 134 solo deben usarse cuando sea absolutamente necesario. El correo 135 electrónico encriptado ha demostrado ser el método de comunicación más 136 efectivo y seguro para estos tipos de problemas. 137 138 Inicio de la divulgación 139 """""""""""""""""""""""" 140 141 La divulgación comienza contactado al equipo de seguridad de hardware del 142 kernel de Linux por correo electrónico. Este contacto inicial debe 143 contener una descripción del problema y una lista de cualquier hardware 144 afectado conocido. Si su organización fabrica o distribuye el hardware 145 afectado, le animamos a considerar también que otro hardware podría estar 146 afectado. 147 148 El equipo de seguridad de hardware proporcionará una lista de correo 149 encriptada específica para el incidente que se utilizará para la discusión 150 inicial con el reportero, la divulgación adicional y la coordinación. 151 152 El equipo de seguridad de hardware proporcionará a la parte reveladora una 153 lista de desarrolladores (expertos de dominios) a quienes se debe informar 154 inicialmente sobre el problema después de confirmar con los 155 desarrolladores que se adherirán a este Memorando de Entendimiento y al 156 proceso documentado. Estos desarrolladores forman el equipo de respuesta 157 inicial y serán responsables de manejar el problema después del contacto 158 inicial. El equipo de seguridad de hardware apoyará al equipo de 159 respuesta, pero no necesariamente involucrandose en el proceso de desarrollo 160 de mitigación. 161 162 Si bien los desarrolladores individuales pueden estar cubiertos por un 163 acuerdo de no divulgación a través de su empleador, no pueden firmar 164 acuerdos individuales de no divulgación en su papel de desarrolladores 165 del kernel de Linux. Sin embargo, aceptarán adherirse a este proceso 166 documentado y al Memorando de Entendimiento. 167 168 La parte reveladora debe proporcionar una lista de contactos para todas 169 las demás entidades ya que han sido, o deberían ser, informadas sobre el 170 problema. Esto sirve para varios propósitos: 171 172 - La lista de entidades divulgadas permite la comunicación en toda la 173 industria, por ejemplo, otros vendedores de OS, vendedores de HW, etc. 174 175 - Las entidades divulgadas pueden ser contactadas para nombrar a expertos 176 que deben participar en el desarrollo de la mitigación. 177 178 - Si un experto que se requiere para manejar un problema es empleado por 179 una entidad cotizada o un miembro de una entidad cotizada, los equipos 180 de respuesta pueden solicitar la divulgación de ese experto a esa 181 entidad. Esto asegura que el experto también forme parte del equipo de 182 respuesta de la entidad. 183 184 Divulgación 185 """"""""""" 186 187 La parte reveladora proporcionará información detallada al equipo de 188 respuesta inicial a través de la lista de correo encriptada especifica. 189 190 Según nuestra experiencia, la documentación técnica de estos problemas 191 suele ser un punto de partida suficiente y es mejor hacer aclaraciones 192 técnicas adicionales a través del correo electrónico. 193 194 Desarrollo de la mitigación 195 """"""""""""""""""""""""""" 196 197 El equipo de respuesta inicial configura una lista de correo encriptada o 198 reutiliza una existente si es apropiada. 199 200 El uso de una lista de correo está cerca del proceso normal de desarrollo 201 de Linux y se ha utilizado con éxito en el desarrollo de mitigación para 202 varios problemas de seguridad de hardware en el pasado. 203 204 La lista de correo funciona en la misma manera que el desarrollo normal de 205 Linux. Los parches se publican, discuten y revisan y, si se acuerda, se 206 aplican a un repositorio git no público al que solo pueden acceder los 207 desarrolladores participantes a través de una conexión segura. El 208 repositorio contiene la rama principal de desarrollo en comparación con 209 el kernel principal y las ramas backport para versiones estables del 210 kernel según sea necesario. 211 212 El equipo de respuesta inicial identificará a más expertos de la 213 comunidad de desarrolladores del kernel de Linux según sea necesario. La 214 incorporación de expertos puede ocurrir en cualquier momento del proceso 215 de desarrollo y debe manejarse de manera oportuna. 216 217 Si un experto es empleado por o es miembro de una entidad en la lista de 218 divulgación proporcionada por la parte reveladora, entonces se solicitará 219 la participación de la entidad pertinente. 220 221 Si no es así, entonces se informará a la parte reveladora sobre la 222 participación de los expertos. Los expertos están cubiertos por el 223 Memorando de Entendimiento y se solicita a la parte reveladora que 224 reconozca la participación. En caso de que la parte reveladora tenga una 225 razón convincente para objetar, entonces esta objeción debe plantearse 226 dentro de los cinco días laborables y resolverse con el equipo de 227 incidente inmediatamente. Si la parte reveladora no reacciona dentro de 228 los cinco días laborables, esto se toma como un reconocimiento silencioso. 229 230 Después del reconocimiento o la resolución de una objeción, el experto es 231 revelado por el equipo de incidente y se incorpora al proceso de 232 desarrollo. 233 234 Lanzamiento coordinado 235 """""""""""""""""""""" 236 237 Las partes involucradas negociarán la fecha y la hora en la que termina el 238 embargo. En ese momento, las mitigaciones preparadas se integran en los 239 árboles de kernel relevantes y se publican. 240 241 Si bien entendemos que los problemas de seguridad del hardware requieren 242 un tiempo de embargo coordinado, el tiempo de embargo debe limitarse al 243 tiempo mínimo que se requiere para que todas las partes involucradas 244 desarrollen, prueben y preparen las mitigaciones. Extender el tiempo de 245 embargo artificialmente para cumplir con las fechas de discusión de la 246 conferencia u otras razones no técnicas está creando más trabajo y carga 247 para los desarrolladores y los equipos de respuesta involucrados, ya que 248 los parches necesitan mantenerse actualizados para seguir el desarrollo en 249 curso del kernel upstream, lo cual podría crear cambios conflictivos. 250 251 Asignación de CVE 252 """"""""""""""""" 253 254 Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial 255 asignan CVEs, ni se requieren para el proceso de desarrollo. Si los CVEs 256 son proporcionados por la parte reveladora, pueden usarse con fines de 257 documentación. 258 259 Embajadores del proceso 260 ----------------------- 261 262 Para obtener asistencia con este proceso, hemos establecido embajadores 263 en varias organizaciones, que pueden responder preguntas o proporcionar 264 orientación sobre el proceso de reporte y el manejo posterior. Los 265 embajadores no están involucrados en la divulgación de un problema en 266 particular, a menos que lo solicite un equipo de respuesta o una parte 267 revelada involucrada. La lista de embajadores actuales: 268 269 ============= ======================================================== 270 AMD Tom Lendacky <thomas.lendacky@amd.com> 271 Ampere Darren Hart <darren@os.amperecomputing.com> 272 ARM Catalin Marinas <catalin.marinas@arm.com> 273 IBM Power Anton Blanchard <anton@linux.ibm.com> 274 IBM Z Christian Borntraeger <borntraeger@de.ibm.com> 275 Intel Tony Luck <tony.luck@intel.com> 276 Qualcomm Trilok Soni <quic_tsoni@quicinc.com> 277 Samsung Javier González <javier.gonz@samsung.com> 278 279 Microsoft James Morris <jamorris@linux.microsoft.com> 280 Xen Andrew Cooper <andrew.cooper3@citrix.com> 281 282 Canonical John Johansen <john.johansen@canonical.com> 283 Debian Ben Hutchings <ben@decadent.org.uk> 284 Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 285 Red Hat Josh Poimboeuf <jpoimboe@redhat.com> 286 SUSE Jiri Kosina <jkosina@suse.cz> 287 288 Google Kees Cook <keescook@chromium.org> 289 290 LLVM Nick Desaulniers <ndesaulniers@google.com> 291 ============= ======================================================== 292 293 Si quiere que su organización se añada a la lista de embajadores, por 294 favor póngase en contacto con el equipo de seguridad de hardware. El 295 embajador nominado tiene que entender y apoyar nuestro proceso 296 completamente y está idealmente bien conectado en la comunidad del kernel 297 de Linux. 298 299 Listas de correo encriptadas 300 ---------------------------- 301 302 Usamos listas de correo encriptadas para la comunicación. El principio de 303 funcionamiento de estas listas es que el correo electrónico enviado a la 304 lista se encripta con la llave PGP de la lista o con el certificado S/MIME 305 de la lista. El software de lista de correo descifra el correo electrónico 306 y lo vuelve a encriptar individualmente para cada suscriptor con la llave 307 PGP del suscriptor o el certificado S/MIME. Los detalles sobre el software 308 de la lista de correo y la configuración que se usa para asegurar la 309 seguridad de las listas y la protección de los datos se pueden encontrar 310 aquí: https://korg.wiki.kernel.org/userdoc/remail. 311 312 Llaves de lista 313 ^^^^^^^^^^^^^^^ 314 315 Para el contacto inicial, consulte :ref:`Contacto`. Para las listas de 316 correo especificas de incidentes, la llave y el certificado S/MIME se 317 envían a los suscriptores por correo electrónico desde la lista 318 especifica. 319 320 Suscripción a listas específicas de incidentes 321 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 322 323 La suscripción es manejada por los equipos de respuesta. Las partes 324 reveladas que quieren participar en la comunicación envían una lista de 325 suscriptores potenciales al equipo de respuesta para que el equipo de 326 respuesta pueda validar las solicitudes de suscripción. 327 328 Cada suscriptor necesita enviar una solicitud de suscripción al equipo de 329 respuesta por correo electrónico. El correo electrónico debe estar firmado 330 con la llave PGP del suscriptor o el certificado S/MIME. Si se usa una 331 llave PGP, debe estar disponible desde un servidor de llave publica y esta 332 idealmente conectada a la red de confianza PGP del kernel de Linux. Véase 333 también: https://www.kernel.org/signature.html. 334 335 El equipo de respuesta verifica que la solicitud del suscriptor sea válida 336 y añade al suscriptor a la lista. Después de la suscripción, el suscriptor 337 recibirá un correo electrónico de la lista que está firmado con la llave 338 PGP de la lista o el certificado S/MIME de la lista. El cliente de correo 339 electrónico del suscriptor puede extraer la llave PGP o el certificado 340 S/MIME de la firma, de modo que el suscriptor pueda enviar correo 341 electrónico encriptado a la lista.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.