Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst

.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/embargoed-hardware-issues.rst
:Translator: Avadhut Naik <avadhut.naik@amd.com>

Problemas de hardware embargados
================================

Alcance
-------

Los problemas de hardware que resultan en problemas de seguridad son una
categoría diferente de errores de seguridad que los errores de software
puro que solo afectan al kernel de Linux.

Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben
tratarse de manera diferente porque usualmente afectan a todos los
sistemas operativos (“OS”) y, por lo tanto, necesitan coordinación entre
vendedores diferentes de OS, distribuciones, vendedores de hardware y
otras partes. Para algunos de los problemas, las mitigaciones de software
pueden depender de actualizaciones de microcódigo o firmware, los cuales
necesitan una coordinación adicional.

.. _Contacto:

Contacto
--------

El equipo de seguridad de hardware del kernel de Linux es separado del
equipo regular de seguridad del kernel de Linux.

El equipo solo maneja la coordinación de los problemas de seguridad de
hardware embargados. Los informes de errores de seguridad de software puro
en el kernel de Linux no son manejados por este equipo y el "reportero"
(quien informa del error) será guiado a contactar el equipo de seguridad
del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su
lugar.

El equipo puede contactar por correo electrónico en
<hardware-security@kernel.org>. Esta es una lista privada de oficiales de
seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro
proceso documentado.

La lista esta encriptada y el correo electrónico a la lista puede ser
enviado por PGP o S/MIME encriptado y debe estar firmado con la llave de
PGP del reportero o el certificado de S/MIME. La llave de PGP y el
certificado de S/MIME de la lista están disponibles en las siguientes
URLs:

  - PGP: https://www.kernel.org/static/files/hardware-security.asc
  - S/MIME: https://www.kernel.org/static/files/hardware-security.crt

Si bien los problemas de seguridad del hardware a menudo son manejados por
el vendedor de hardware afectado, damos la bienvenida al contacto de
investigadores o individuos que hayan identificado una posible falla de
hardware.

Oficiales de seguridad de hardware
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

El equipo actual de oficiales de seguridad de hardware:

  - Linus Torvalds (Linux Foundation Fellow)
  - Greg Kroah-Hartman (Linux Foundation Fellow)
  - Thomas Gleixner (Linux Foundation Fellow)

Operación de listas de correo
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Las listas de correo encriptadas que se utilizan en nuestro proceso están
alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar
este servicio, los miembros del personal de operaciones de IT de la
Fundación Linux técnicamente tienen la capacidad de acceder a la
información embargada, pero están obligados a la confidencialidad por su
contrato de trabajo. El personal de IT de la Fundación Linux también es
responsable para operar y administrar el resto de la infraestructura de
kernel.org.

El actual director de infraestructura de proyecto de IT de la Fundación
Linux es Konstantin Ryabitsev.

Acuerdos de no divulgación
--------------------------

El equipo de seguridad de hardware del kernel de Linux no es un organismo
formal y, por lo tanto, no puede firmar cualquier acuerdo de no
divulgación. La comunidad del kernel es consciente de la naturaleza
delicada de tales problemas y ofrece un Memorando de Entendimiento en su
lugar.

Memorando de Entendimiento
--------------------------

La comunidad del kernel de Linux tiene una comprensión profunda del
requisito de mantener los problemas de seguridad de hardware bajo embargo
para la coordinación entre diferentes vendedores de OS, distribuidores,
vendedores de hardware y otras partes.

La comunidad del kernel de Linux ha manejado con éxito los problemas de
seguridad del hardware en el pasado y tiene los mecanismos necesarios para
permitir el desarrollo compatible con la comunidad bajo restricciones de
embargo.

La comunidad del kernel de Linux tiene un equipo de seguridad de hardware
dedicado para el contacto inicial, el cual supervisa el proceso de manejo
de tales problemas bajo las reglas de embargo.

El equipo de seguridad de hardware identifica a los desarrolladores
(expertos en dominio) que formarán el equipo de respuesta inicial para un
problema en particular. El equipo de respuesta inicial puede involucrar
más desarrolladores (expertos en dominio) para abordar el problema de la
mejor manera técnica.

Todos los desarrolladores involucrados se comprometen a adherirse a las
reglas del embargo y a mantener confidencial la información recibida. La
violación de la promesa conducirá a la exclusión inmediata del problema
actual y la eliminación de todas las listas de correo relacionadas.
Además, el equipo de seguridad de hardware también excluirá al
delincuente de problemas futuros. El impacto de esta consecuencia es un
elemento de disuasión altamente efectivo en nuestra comunidad. En caso de
que ocurra una violación, el equipo de seguridad de hardware informará a
las partes involucradas inmediatamente. Si usted o alguien tiene
conocimiento de una posible violación, por favor, infórmelo inmediatamente
a los oficiales de seguridad de hardware.

Proceso
^^^^^^^

Debido a la naturaleza distribuida globalmente del desarrollo del kernel
de Linux, las reuniones cara a cara hacen imposible abordar los
problemas de seguridad del hardware. Las conferencias telefónicas son
difíciles de coordinar debido a las zonas horarias y otros factores y
solo deben usarse cuando sea absolutamente necesario. El correo
electrónico encriptado ha demostrado ser el método de comunicación más
efectivo y seguro para estos tipos de problemas.

Inicio de la divulgación
""""""""""""""""""""""""

La divulgación comienza contactado al equipo de seguridad de hardware del
kernel de Linux por correo electrónico. Este contacto inicial debe
contener una descripción del problema y una lista de cualquier hardware
afectado conocido. Si su organización fabrica o distribuye el hardware
afectado, le animamos a considerar también que otro hardware podría estar
afectado.

El equipo de seguridad de hardware proporcionará una lista de correo
encriptada específica para el incidente que se utilizará para la discusión
inicial con el reportero, la divulgación adicional y la coordinación.

El equipo de seguridad de hardware proporcionará a la parte reveladora una
lista de desarrolladores (expertos de dominios) a quienes se debe informar
inicialmente sobre el problema después de confirmar con los
desarrolladores que se adherirán a este Memorando de Entendimiento y al
proceso documentado. Estos desarrolladores forman el equipo de respuesta
inicial y serán responsables de manejar el problema después del contacto
inicial. El equipo de seguridad de hardware apoyará al equipo de
respuesta, pero no necesariamente involucrandose en el proceso de desarrollo
de mitigación.

Si bien los desarrolladores individuales pueden estar cubiertos por un
acuerdo de no divulgación a través de su empleador, no pueden firmar
acuerdos individuales de no divulgación en su papel de desarrolladores
del kernel de Linux. Sin embargo, aceptarán adherirse a este proceso
documentado y al Memorando de Entendimiento.

La parte reveladora debe proporcionar una lista de contactos para todas
las demás entidades ya que han sido, o deberían ser, informadas sobre el
problema. Esto sirve para varios propósitos:

 - La lista de entidades divulgadas permite la comunicación en toda la
   industria, por ejemplo, otros vendedores de OS, vendedores de HW, etc.

 - Las entidades divulgadas pueden ser contactadas para nombrar a expertos
   que deben participar en el desarrollo de la mitigación.

 - Si un experto que se requiere para manejar un problema es empleado por
   una entidad cotizada o un miembro de una entidad cotizada, los equipos
   de respuesta pueden solicitar la divulgación de ese experto a esa
   entidad. Esto asegura que el experto también forme parte del equipo de
   respuesta de la entidad.

Divulgación
"""""""""""

La parte reveladora proporcionará información detallada al equipo de
respuesta inicial a través de la lista de correo encriptada especifica.

Según nuestra experiencia, la documentación técnica de estos problemas
suele ser un punto de partida suficiente y es mejor hacer aclaraciones
técnicas adicionales a través del correo electrónico.

Desarrollo de la mitigación
"""""""""""""""""""""""""""

El equipo de respuesta inicial configura una lista de correo encriptada o
reutiliza una existente si es apropiada.

El uso de una lista de correo está cerca del proceso normal de desarrollo
de Linux y se ha utilizado con éxito en el desarrollo de mitigación para
varios problemas de seguridad de hardware en el pasado.

La lista de correo funciona en la misma manera que el desarrollo normal de
Linux. Los parches se publican, discuten y revisan y, si se acuerda, se
aplican a un repositorio git no público al que solo pueden acceder los
desarrolladores participantes a través de una conexión segura. El
repositorio contiene la rama principal de desarrollo en comparación con
el kernel principal y las ramas backport para versiones estables del
kernel según sea necesario.

El equipo de respuesta inicial identificará a más expertos de la
comunidad de desarrolladores del kernel de Linux según sea necesario. La
incorporación de expertos puede ocurrir en cualquier momento del proceso
de desarrollo y debe manejarse de manera oportuna.

Si un experto es empleado por o es miembro de una entidad en la lista de
divulgación proporcionada por la parte reveladora, entonces se solicitará
la participación de la entidad pertinente.

Si no es así, entonces se informará a la parte reveladora sobre la
participación de los expertos. Los expertos están cubiertos por el
Memorando de Entendimiento y se solicita a la parte reveladora que
reconozca la participación. En caso de que la parte reveladora tenga una
razón convincente para objetar, entonces esta objeción debe plantearse
dentro de los cinco días laborables y resolverse con el equipo de
incidente inmediatamente. Si la parte reveladora no reacciona dentro de
los cinco días laborables, esto se toma como un reconocimiento silencioso.

Después del reconocimiento o la resolución de una objeción, el experto es
revelado por el equipo de incidente y se incorpora al proceso de
desarrollo.

Lanzamiento coordinado
""""""""""""""""""""""

Las partes involucradas negociarán la fecha y la hora en la que termina el
embargo. En ese momento, las mitigaciones preparadas se integran en los
árboles de kernel relevantes y se publican.

Si bien entendemos que los problemas de seguridad del hardware requieren
un tiempo de embargo coordinado, el tiempo de embargo debe limitarse al
tiempo mínimo que se requiere para que todas las partes involucradas
desarrollen, prueben y preparen las mitigaciones. Extender el tiempo de
embargo artificialmente para cumplir con las fechas de discusión de la
conferencia u otras razones no técnicas está creando más trabajo y carga
para los desarrolladores y los equipos de respuesta involucrados, ya que
los parches necesitan mantenerse actualizados para seguir el desarrollo en
curso del kernel upstream, lo cual podría crear cambios conflictivos.

Asignación de CVE
"""""""""""""""""

Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial
asignan CVEs, ni se requieren para el proceso de desarrollo. Si los CVEs
son proporcionados por la parte reveladora, pueden usarse con fines de
documentación.

Embajadores del proceso
-----------------------

Para obtener asistencia con este proceso, hemos establecido embajadores
en varias organizaciones, que pueden responder preguntas o proporcionar
orientación sobre el proceso de reporte y el manejo posterior. Los
embajadores no están involucrados en la divulgación de un problema en
particular, a menos que lo solicite un equipo de respuesta o una parte
revelada involucrada. La lista de embajadores actuales:

  ============= ========================================================
  AMD		Tom Lendacky <thomas.lendacky@amd.com>
  Ampere	Darren Hart <darren@os.amperecomputing.com>
  ARM		Catalin Marinas <catalin.marinas@arm.com>
  IBM Power	Anton Blanchard <anton@linux.ibm.com>
  IBM Z		Christian Borntraeger <borntraeger@de.ibm.com>
  Intel		Tony Luck <tony.luck@intel.com>
  Qualcomm	Trilok Soni <quic_tsoni@quicinc.com>
  Samsung	Javier González <javier.gonz@samsung.com>

  Microsoft	James Morris <jamorris@linux.microsoft.com>
  Xen		Andrew Cooper <andrew.cooper3@citrix.com>

  Canonical	John Johansen <john.johansen@canonical.com>
  Debian	Ben Hutchings <ben@decadent.org.uk>
  Oracle	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Red Hat	Josh Poimboeuf <jpoimboe@redhat.com>
  SUSE		Jiri Kosina <jkosina@suse.cz>

  Google	Kees Cook <keescook@chromium.org>

  LLVM		Nick Desaulniers <ndesaulniers@google.com>
  ============= ========================================================

Si quiere que su organización se añada a la lista de embajadores, por
favor póngase en contacto con el equipo de seguridad de hardware. El
embajador nominado tiene que entender y apoyar nuestro proceso
completamente y está idealmente bien conectado en la comunidad del kernel
de Linux.

Listas de correo encriptadas
----------------------------

Usamos listas de correo encriptadas para la comunicación. El principio de
funcionamiento de estas listas es que el correo electrónico enviado a la
lista se encripta con la llave PGP de la lista o con el certificado S/MIME
de la lista. El software de lista de correo descifra el correo electrónico
y lo vuelve a encriptar individualmente para cada suscriptor con la llave
PGP del suscriptor o el certificado S/MIME. Los detalles sobre el software
de la lista de correo y la configuración que se usa para asegurar la
seguridad de las listas y la protección de los datos se pueden encontrar
aquí: https://korg.wiki.kernel.org/userdoc/remail.

Llaves de lista
^^^^^^^^^^^^^^^

Para el contacto inicial, consulte :ref:`Contacto`. Para las listas de
correo especificas de incidentes, la llave y el certificado S/MIME se
envían a los suscriptores por correo electrónico desde la lista
especifica.

Suscripción a listas específicas de incidentes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

La suscripción es manejada por los equipos de respuesta. Las partes
reveladas que quieren participar en la comunicación envían una lista de
suscriptores potenciales al equipo de respuesta para que el equipo de
respuesta pueda validar las solicitudes de suscripción.

Cada suscriptor necesita enviar una solicitud de suscripción al equipo de
respuesta por correo electrónico. El correo electrónico debe estar firmado
con la llave PGP del suscriptor o el certificado S/MIME. Si se usa una
llave PGP, debe estar disponible desde un servidor de llave publica y esta
idealmente conectada a la red de confianza PGP del kernel de Linux. Véase
también: https://www.kernel.org/signature.html.

El equipo de respuesta verifica que la solicitud del suscriptor sea válida
y añade al suscriptor a la lista. Después de la suscripción, el suscriptor
recibirá un correo electrónico de la lista que está firmado con la llave
PGP de la lista o el certificado S/MIME de la lista. El cliente de correo
electrónico del suscriptor puede extraer la llave PGP o el certificado
S/MIME de la firma, de modo que el suscriptor pueda enviar correo
electrónico encriptado a la lista.