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 7Problemas de hardware embargados 8================================ 9 10Alcance 11------- 12 13Los problemas de hardware que resultan en problemas de seguridad son una 14categoría diferente de errores de seguridad que los errores de software 15puro que solo afectan al kernel de Linux. 16 17Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben 18tratarse de manera diferente porque usualmente afectan a todos los 19sistemas operativos (“OS”) y, por lo tanto, necesitan coordinación entre 20vendedores diferentes de OS, distribuciones, vendedores de hardware y 21otras partes. Para algunos de los problemas, las mitigaciones de software 22pueden depender de actualizaciones de microcódigo o firmware, los cuales 23necesitan una coordinación adicional. 24 25.. _Contacto: 26 27Contacto 28-------- 29 30El equipo de seguridad de hardware del kernel de Linux es separado del 31equipo regular de seguridad del kernel de Linux. 32 33El equipo solo maneja la coordinación de los problemas de seguridad de 34hardware embargados. Los informes de errores de seguridad de software puro 35en 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 37del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su 38lugar. 39 40El equipo puede contactar por correo electrónico en 41<hardware-security@kernel.org>. Esta es una lista privada de oficiales de 42seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro 43proceso documentado. 44 45La lista esta encriptada y el correo electrónico a la lista puede ser 46enviado por PGP o S/MIME encriptado y debe estar firmado con la llave de 47PGP del reportero o el certificado de S/MIME. La llave de PGP y el 48certificado de S/MIME de la lista están disponibles en las siguientes 49URLs: 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 54Si bien los problemas de seguridad del hardware a menudo son manejados por 55el vendedor de hardware afectado, damos la bienvenida al contacto de 56investigadores o individuos que hayan identificado una posible falla de 57hardware. 58 59Oficiales de seguridad de hardware 60^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 61 62El 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 68Operación de listas de correo 69^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 70 71Las listas de correo encriptadas que se utilizan en nuestro proceso están 72alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar 73este servicio, los miembros del personal de operaciones de IT de la 74Fundación Linux técnicamente tienen la capacidad de acceder a la 75información embargada, pero están obligados a la confidencialidad por su 76contrato de trabajo. El personal de IT de la Fundación Linux también es 77responsable para operar y administrar el resto de la infraestructura de 78kernel.org. 79 80El actual director de infraestructura de proyecto de IT de la Fundación 81Linux es Konstantin Ryabitsev. 82 83Acuerdos de no divulgación 84-------------------------- 85 86El equipo de seguridad de hardware del kernel de Linux no es un organismo 87formal y, por lo tanto, no puede firmar cualquier acuerdo de no 88divulgación. La comunidad del kernel es consciente de la naturaleza 89delicada de tales problemas y ofrece un Memorando de Entendimiento en su 90lugar. 91 92Memorando de Entendimiento 93-------------------------- 94 95La comunidad del kernel de Linux tiene una comprensión profunda del 96requisito de mantener los problemas de seguridad de hardware bajo embargo 97para la coordinación entre diferentes vendedores de OS, distribuidores, 98vendedores de hardware y otras partes. 99 100La comunidad del kernel de Linux ha manejado con éxito los problemas de 101seguridad del hardware en el pasado y tiene los mecanismos necesarios para 102permitir el desarrollo compatible con la comunidad bajo restricciones de 103embargo. 104 105La comunidad del kernel de Linux tiene un equipo de seguridad de hardware 106dedicado para el contacto inicial, el cual supervisa el proceso de manejo 107de tales problemas bajo las reglas de embargo. 108 109El equipo de seguridad de hardware identifica a los desarrolladores 110(expertos en dominio) que formarán el equipo de respuesta inicial para un 111problema en particular. El equipo de respuesta inicial puede involucrar 112más desarrolladores (expertos en dominio) para abordar el problema de la 113mejor manera técnica. 114 115Todos los desarrolladores involucrados se comprometen a adherirse a las 116reglas del embargo y a mantener confidencial la información recibida. La 117violación de la promesa conducirá a la exclusión inmediata del problema 118actual y la eliminación de todas las listas de correo relacionadas. 119Además, el equipo de seguridad de hardware también excluirá al 120delincuente de problemas futuros. El impacto de esta consecuencia es un 121elemento de disuasión altamente efectivo en nuestra comunidad. En caso de 122que ocurra una violación, el equipo de seguridad de hardware informará a 123las partes involucradas inmediatamente. Si usted o alguien tiene 124conocimiento de una posible violación, por favor, infórmelo inmediatamente 125a los oficiales de seguridad de hardware. 126 127Proceso 128^^^^^^^ 129 130Debido a la naturaleza distribuida globalmente del desarrollo del kernel 131de Linux, las reuniones cara a cara hacen imposible abordar los 132problemas de seguridad del hardware. Las conferencias telefónicas son 133difíciles de coordinar debido a las zonas horarias y otros factores y 134solo deben usarse cuando sea absolutamente necesario. El correo 135electrónico encriptado ha demostrado ser el método de comunicación más 136efectivo y seguro para estos tipos de problemas. 137 138Inicio de la divulgación 139"""""""""""""""""""""""" 140 141La divulgación comienza contactado al equipo de seguridad de hardware del 142kernel de Linux por correo electrónico. Este contacto inicial debe 143contener una descripción del problema y una lista de cualquier hardware 144afectado conocido. Si su organización fabrica o distribuye el hardware 145afectado, le animamos a considerar también que otro hardware podría estar 146afectado. 147 148El equipo de seguridad de hardware proporcionará una lista de correo 149encriptada específica para el incidente que se utilizará para la discusión 150inicial con el reportero, la divulgación adicional y la coordinación. 151 152El equipo de seguridad de hardware proporcionará a la parte reveladora una 153lista de desarrolladores (expertos de dominios) a quienes se debe informar 154inicialmente sobre el problema después de confirmar con los 155desarrolladores que se adherirán a este Memorando de Entendimiento y al 156proceso documentado. Estos desarrolladores forman el equipo de respuesta 157inicial y serán responsables de manejar el problema después del contacto 158inicial. El equipo de seguridad de hardware apoyará al equipo de 159respuesta, pero no necesariamente involucrandose en el proceso de desarrollo 160de mitigación. 161 162Si bien los desarrolladores individuales pueden estar cubiertos por un 163acuerdo de no divulgación a través de su empleador, no pueden firmar 164acuerdos individuales de no divulgación en su papel de desarrolladores 165del kernel de Linux. Sin embargo, aceptarán adherirse a este proceso 166documentado y al Memorando de Entendimiento. 167 168La parte reveladora debe proporcionar una lista de contactos para todas 169las demás entidades ya que han sido, o deberían ser, informadas sobre el 170problema. 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 184Divulgación 185""""""""""" 186 187La parte reveladora proporcionará información detallada al equipo de 188respuesta inicial a través de la lista de correo encriptada especifica. 189 190Según nuestra experiencia, la documentación técnica de estos problemas 191suele ser un punto de partida suficiente y es mejor hacer aclaraciones 192técnicas adicionales a través del correo electrónico. 193 194Desarrollo de la mitigación 195""""""""""""""""""""""""""" 196 197El equipo de respuesta inicial configura una lista de correo encriptada o 198reutiliza una existente si es apropiada. 199 200El uso de una lista de correo está cerca del proceso normal de desarrollo 201de Linux y se ha utilizado con éxito en el desarrollo de mitigación para 202varios problemas de seguridad de hardware en el pasado. 203 204La lista de correo funciona en la misma manera que el desarrollo normal de 205Linux. Los parches se publican, discuten y revisan y, si se acuerda, se 206aplican a un repositorio git no público al que solo pueden acceder los 207desarrolladores participantes a través de una conexión segura. El 208repositorio contiene la rama principal de desarrollo en comparación con 209el kernel principal y las ramas backport para versiones estables del 210kernel según sea necesario. 211 212El equipo de respuesta inicial identificará a más expertos de la 213comunidad de desarrolladores del kernel de Linux según sea necesario. La 214incorporación de expertos puede ocurrir en cualquier momento del proceso 215de desarrollo y debe manejarse de manera oportuna. 216 217Si un experto es empleado por o es miembro de una entidad en la lista de 218divulgación proporcionada por la parte reveladora, entonces se solicitará 219la participación de la entidad pertinente. 220 221Si no es así, entonces se informará a la parte reveladora sobre la 222participación de los expertos. Los expertos están cubiertos por el 223Memorando de Entendimiento y se solicita a la parte reveladora que 224reconozca la participación. En caso de que la parte reveladora tenga una 225razón convincente para objetar, entonces esta objeción debe plantearse 226dentro de los cinco días laborables y resolverse con el equipo de 227incidente inmediatamente. Si la parte reveladora no reacciona dentro de 228los cinco días laborables, esto se toma como un reconocimiento silencioso. 229 230Después del reconocimiento o la resolución de una objeción, el experto es 231revelado por el equipo de incidente y se incorpora al proceso de 232desarrollo. 233 234Lanzamiento coordinado 235"""""""""""""""""""""" 236 237Las partes involucradas negociarán la fecha y la hora en la que termina el 238embargo. En ese momento, las mitigaciones preparadas se integran en los 239árboles de kernel relevantes y se publican. 240 241Si bien entendemos que los problemas de seguridad del hardware requieren 242un tiempo de embargo coordinado, el tiempo de embargo debe limitarse al 243tiempo mínimo que se requiere para que todas las partes involucradas 244desarrollen, prueben y preparen las mitigaciones. Extender el tiempo de 245embargo artificialmente para cumplir con las fechas de discusión de la 246conferencia u otras razones no técnicas está creando más trabajo y carga 247para los desarrolladores y los equipos de respuesta involucrados, ya que 248los parches necesitan mantenerse actualizados para seguir el desarrollo en 249curso del kernel upstream, lo cual podría crear cambios conflictivos. 250 251Asignación de CVE 252""""""""""""""""" 253 254Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial 255asignan CVEs, ni se requieren para el proceso de desarrollo. Si los CVEs 256son proporcionados por la parte reveladora, pueden usarse con fines de 257documentación. 258 259Embajadores del proceso 260----------------------- 261 262Para obtener asistencia con este proceso, hemos establecido embajadores 263en varias organizaciones, que pueden responder preguntas o proporcionar 264orientación sobre el proceso de reporte y el manejo posterior. Los 265embajadores no están involucrados en la divulgación de un problema en 266particular, a menos que lo solicite un equipo de respuesta o una parte 267revelada 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 293Si quiere que su organización se añada a la lista de embajadores, por 294favor póngase en contacto con el equipo de seguridad de hardware. El 295embajador nominado tiene que entender y apoyar nuestro proceso 296completamente y está idealmente bien conectado en la comunidad del kernel 297de Linux. 298 299Listas de correo encriptadas 300---------------------------- 301 302Usamos listas de correo encriptadas para la comunicación. El principio de 303funcionamiento de estas listas es que el correo electrónico enviado a la 304lista se encripta con la llave PGP de la lista o con el certificado S/MIME 305de la lista. El software de lista de correo descifra el correo electrónico 306y lo vuelve a encriptar individualmente para cada suscriptor con la llave 307PGP del suscriptor o el certificado S/MIME. Los detalles sobre el software 308de la lista de correo y la configuración que se usa para asegurar la 309seguridad de las listas y la protección de los datos se pueden encontrar 310aquí: https://korg.wiki.kernel.org/userdoc/remail. 311 312Llaves de lista 313^^^^^^^^^^^^^^^ 314 315Para el contacto inicial, consulte :ref:`Contacto`. Para las listas de 316correo especificas de incidentes, la llave y el certificado S/MIME se 317envían a los suscriptores por correo electrónico desde la lista 318especifica. 319 320Suscripción a listas específicas de incidentes 321^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 322 323La suscripción es manejada por los equipos de respuesta. Las partes 324reveladas que quieren participar en la comunicación envían una lista de 325suscriptores potenciales al equipo de respuesta para que el equipo de 326respuesta pueda validar las solicitudes de suscripción. 327 328Cada suscriptor necesita enviar una solicitud de suscripción al equipo de 329respuesta por correo electrónico. El correo electrónico debe estar firmado 330con la llave PGP del suscriptor o el certificado S/MIME. Si se usa una 331llave PGP, debe estar disponible desde un servidor de llave publica y esta 332idealmente conectada a la red de confianza PGP del kernel de Linux. Véase 333también: https://www.kernel.org/signature.html. 334 335El equipo de respuesta verifica que la solicitud del suscriptor sea válida 336y añade al suscriptor a la lista. Después de la suscripción, el suscriptor 337recibirá un correo electrónico de la lista que está firmado con la llave 338PGP de la lista o el certificado S/MIME de la lista. El cliente de correo 339electrónico del suscriptor puede extraer la llave PGP o el certificado 340S/MIME de la firma, de modo que el suscriptor pueda enviar correo 341electrónico encriptado a la lista. 342