342 lines · plain
1.. SPDX-License-Identifier: GPL-2.02.. include:: ../disclaimer-sp.rst3 4:Original: Documentation/process/embargoed-hardware-issues.rst5:Translator: Avadhut Naik <avadhut.naik@amd.com>6 7Problemas de hardware embargados8================================9 10Alcance11-------12 13Los problemas de hardware que resultan en problemas de seguridad son una14categoría diferente de errores de seguridad que los errores de software15puro que solo afectan al kernel de Linux.16 17Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben18tratarse de manera diferente porque usualmente afectan a todos los19sistemas operativos (“OS”) y, por lo tanto, necesitan coordinación entre20vendedores diferentes de OS, distribuciones, vendedores de hardware y21otras partes. Para algunos de los problemas, las mitigaciones de software22pueden depender de actualizaciones de microcódigo o firmware, los cuales23necesitan una coordinación adicional.24 25.. _Contacto:26 27Contacto28--------29 30El equipo de seguridad de hardware del kernel de Linux es separado del31equipo regular de seguridad del kernel de Linux.32 33El equipo solo maneja la coordinación de los problemas de seguridad de34hardware embargados. Los informes de errores de seguridad de software puro35en 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 seguridad37del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su38lugar.39 40El equipo puede contactar por correo electrónico en41<hardware-security@kernel.org>. Esta es una lista privada de oficiales de42seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro43proceso documentado.44 45La lista esta encriptada y el correo electrónico a la lista puede ser46enviado por PGP o S/MIME encriptado y debe estar firmado con la llave de47PGP del reportero o el certificado de S/MIME. La llave de PGP y el48certificado de S/MIME de la lista están disponibles en las siguientes49URLs:50 51 - PGP: https://www.kernel.org/static/files/hardware-security.asc52 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt53 54Si bien los problemas de seguridad del hardware a menudo son manejados por55el vendedor de hardware afectado, damos la bienvenida al contacto de56investigadores o individuos que hayan identificado una posible falla de57hardware.58 59Oficiales de seguridad de hardware60^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^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 correo69^^^^^^^^^^^^^^^^^^^^^^^^^^^^^70 71Las listas de correo encriptadas que se utilizan en nuestro proceso están72alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar73este servicio, los miembros del personal de operaciones de IT de la74Fundación Linux técnicamente tienen la capacidad de acceder a la75información embargada, pero están obligados a la confidencialidad por su76contrato de trabajo. El personal de IT de la Fundación Linux también es77responsable para operar y administrar el resto de la infraestructura de78kernel.org.79 80El actual director de infraestructura de proyecto de IT de la Fundación81Linux es Konstantin Ryabitsev.82 83Acuerdos de no divulgación84--------------------------85 86El equipo de seguridad de hardware del kernel de Linux no es un organismo87formal y, por lo tanto, no puede firmar cualquier acuerdo de no88divulgación. La comunidad del kernel es consciente de la naturaleza89delicada de tales problemas y ofrece un Memorando de Entendimiento en su90lugar.91 92Memorando de Entendimiento93--------------------------94 95La comunidad del kernel de Linux tiene una comprensión profunda del96requisito de mantener los problemas de seguridad de hardware bajo embargo97para 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 de101seguridad del hardware en el pasado y tiene los mecanismos necesarios para102permitir el desarrollo compatible con la comunidad bajo restricciones de103embargo.104 105La comunidad del kernel de Linux tiene un equipo de seguridad de hardware106dedicado para el contacto inicial, el cual supervisa el proceso de manejo107de tales problemas bajo las reglas de embargo.108 109El equipo de seguridad de hardware identifica a los desarrolladores110(expertos en dominio) que formarán el equipo de respuesta inicial para un111problema en particular. El equipo de respuesta inicial puede involucrar112más desarrolladores (expertos en dominio) para abordar el problema de la113mejor manera técnica.114 115Todos los desarrolladores involucrados se comprometen a adherirse a las116reglas del embargo y a mantener confidencial la información recibida. La117violación de la promesa conducirá a la exclusión inmediata del problema118actual y la eliminación de todas las listas de correo relacionadas.119Además, el equipo de seguridad de hardware también excluirá al120delincuente de problemas futuros. El impacto de esta consecuencia es un121elemento de disuasión altamente efectivo en nuestra comunidad. En caso de122que ocurra una violación, el equipo de seguridad de hardware informará a123las partes involucradas inmediatamente. Si usted o alguien tiene124conocimiento de una posible violación, por favor, infórmelo inmediatamente125a los oficiales de seguridad de hardware.126 127Proceso128^^^^^^^129 130Debido a la naturaleza distribuida globalmente del desarrollo del kernel131de Linux, las reuniones cara a cara hacen imposible abordar los132problemas de seguridad del hardware. Las conferencias telefónicas son133difíciles de coordinar debido a las zonas horarias y otros factores y134solo deben usarse cuando sea absolutamente necesario. El correo135electrónico encriptado ha demostrado ser el método de comunicación más136efectivo y seguro para estos tipos de problemas.137 138Inicio de la divulgación139""""""""""""""""""""""""140 141La divulgación comienza contactado al equipo de seguridad de hardware del142kernel de Linux por correo electrónico. Este contacto inicial debe143contener una descripción del problema y una lista de cualquier hardware144afectado conocido. Si su organización fabrica o distribuye el hardware145afectado, le animamos a considerar también que otro hardware podría estar146afectado.147 148El equipo de seguridad de hardware proporcionará una lista de correo149encriptada específica para el incidente que se utilizará para la discusión150inicial con el reportero, la divulgación adicional y la coordinación.151 152El equipo de seguridad de hardware proporcionará a la parte reveladora una153lista de desarrolladores (expertos de dominios) a quienes se debe informar154inicialmente sobre el problema después de confirmar con los155desarrolladores que se adherirán a este Memorando de Entendimiento y al156proceso documentado. Estos desarrolladores forman el equipo de respuesta157inicial y serán responsables de manejar el problema después del contacto158inicial. El equipo de seguridad de hardware apoyará al equipo de159respuesta, pero no necesariamente involucrandose en el proceso de desarrollo160de mitigación.161 162Si bien los desarrolladores individuales pueden estar cubiertos por un163acuerdo de no divulgación a través de su empleador, no pueden firmar164acuerdos individuales de no divulgación en su papel de desarrolladores165del kernel de Linux. Sin embargo, aceptarán adherirse a este proceso166documentado y al Memorando de Entendimiento.167 168La parte reveladora debe proporcionar una lista de contactos para todas169las demás entidades ya que han sido, o deberían ser, informadas sobre el170problema. Esto sirve para varios propósitos:171 172 - La lista de entidades divulgadas permite la comunicación en toda la173 industria, por ejemplo, otros vendedores de OS, vendedores de HW, etc.174 175 - Las entidades divulgadas pueden ser contactadas para nombrar a expertos176 que deben participar en el desarrollo de la mitigación.177 178 - Si un experto que se requiere para manejar un problema es empleado por179 una entidad cotizada o un miembro de una entidad cotizada, los equipos180 de respuesta pueden solicitar la divulgación de ese experto a esa181 entidad. Esto asegura que el experto también forme parte del equipo de182 respuesta de la entidad.183 184Divulgación185"""""""""""186 187La parte reveladora proporcionará información detallada al equipo de188respuesta inicial a través de la lista de correo encriptada especifica.189 190Según nuestra experiencia, la documentación técnica de estos problemas191suele ser un punto de partida suficiente y es mejor hacer aclaraciones192técnicas adicionales a través del correo electrónico.193 194Desarrollo de la mitigación195"""""""""""""""""""""""""""196 197El equipo de respuesta inicial configura una lista de correo encriptada o198reutiliza una existente si es apropiada.199 200El uso de una lista de correo está cerca del proceso normal de desarrollo201de Linux y se ha utilizado con éxito en el desarrollo de mitigación para202varios problemas de seguridad de hardware en el pasado.203 204La lista de correo funciona en la misma manera que el desarrollo normal de205Linux. Los parches se publican, discuten y revisan y, si se acuerda, se206aplican a un repositorio git no público al que solo pueden acceder los207desarrolladores participantes a través de una conexión segura. El208repositorio contiene la rama principal de desarrollo en comparación con209el kernel principal y las ramas backport para versiones estables del210kernel según sea necesario.211 212El equipo de respuesta inicial identificará a más expertos de la213comunidad de desarrolladores del kernel de Linux según sea necesario. La214incorporación de expertos puede ocurrir en cualquier momento del proceso215de desarrollo y debe manejarse de manera oportuna.216 217Si un experto es empleado por o es miembro de una entidad en la lista de218divulgació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 la222participación de los expertos. Los expertos están cubiertos por el223Memorando de Entendimiento y se solicita a la parte reveladora que224reconozca la participación. En caso de que la parte reveladora tenga una225razón convincente para objetar, entonces esta objeción debe plantearse226dentro de los cinco días laborables y resolverse con el equipo de227incidente inmediatamente. Si la parte reveladora no reacciona dentro de228los 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 es231revelado por el equipo de incidente y se incorpora al proceso de232desarrollo.233 234Lanzamiento coordinado235""""""""""""""""""""""236 237Las partes involucradas negociarán la fecha y la hora en la que termina el238embargo. En ese momento, las mitigaciones preparadas se integran en los239árboles de kernel relevantes y se publican.240 241Si bien entendemos que los problemas de seguridad del hardware requieren242un tiempo de embargo coordinado, el tiempo de embargo debe limitarse al243tiempo mínimo que se requiere para que todas las partes involucradas244desarrollen, prueben y preparen las mitigaciones. Extender el tiempo de245embargo artificialmente para cumplir con las fechas de discusión de la246conferencia u otras razones no técnicas está creando más trabajo y carga247para los desarrolladores y los equipos de respuesta involucrados, ya que248los parches necesitan mantenerse actualizados para seguir el desarrollo en249curso del kernel upstream, lo cual podría crear cambios conflictivos.250 251Asignación de CVE252"""""""""""""""""253 254Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial255asignan CVEs, ni se requieren para el proceso de desarrollo. Si los CVEs256son proporcionados por la parte reveladora, pueden usarse con fines de257documentación.258 259Embajadores del proceso260-----------------------261 262Para obtener asistencia con este proceso, hemos establecido embajadores263en varias organizaciones, que pueden responder preguntas o proporcionar264orientación sobre el proceso de reporte y el manejo posterior. Los265embajadores no están involucrados en la divulgación de un problema en266particular, a menos que lo solicite un equipo de respuesta o una parte267revelada 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, por294favor póngase en contacto con el equipo de seguridad de hardware. El295embajador nominado tiene que entender y apoyar nuestro proceso296completamente y está idealmente bien conectado en la comunidad del kernel297de Linux.298 299Listas de correo encriptadas300----------------------------301 302Usamos listas de correo encriptadas para la comunicación. El principio de303funcionamiento de estas listas es que el correo electrónico enviado a la304lista se encripta con la llave PGP de la lista o con el certificado S/MIME305de la lista. El software de lista de correo descifra el correo electrónico306y lo vuelve a encriptar individualmente para cada suscriptor con la llave307PGP del suscriptor o el certificado S/MIME. Los detalles sobre el software308de la lista de correo y la configuración que se usa para asegurar la309seguridad de las listas y la protección de los datos se pueden encontrar310aquí: https://korg.wiki.kernel.org/userdoc/remail.311 312Llaves de lista313^^^^^^^^^^^^^^^314 315Para el contacto inicial, consulte :ref:`Contacto`. Para las listas de316correo especificas de incidentes, la llave y el certificado S/MIME se317envían a los suscriptores por correo electrónico desde la lista318especifica.319 320Suscripción a listas específicas de incidentes321^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^322 323La suscripción es manejada por los equipos de respuesta. Las partes324reveladas que quieren participar en la comunicación envían una lista de325suscriptores potenciales al equipo de respuesta para que el equipo de326respuesta pueda validar las solicitudes de suscripción.327 328Cada suscriptor necesita enviar una solicitud de suscripción al equipo de329respuesta por correo electrónico. El correo electrónico debe estar firmado330con la llave PGP del suscriptor o el certificado S/MIME. Si se usa una331llave PGP, debe estar disponible desde un servidor de llave publica y esta332idealmente conectada a la red de confianza PGP del kernel de Linux. Véase333también: https://www.kernel.org/signature.html.334 335El equipo de respuesta verifica que la solicitud del suscriptor sea válida336y añade al suscriptor a la lista. Después de la suscripción, el suscriptor337recibirá un correo electrónico de la lista que está firmado con la llave338PGP de la lista o el certificado S/MIME de la lista. El cliente de correo339electrónico del suscriptor puede extraer la llave PGP o el certificado340S/MIME de la firma, de modo que el suscriptor pueda enviar correo341electrónico encriptado a la lista.342