1.. SPDX-License-Identifier: GPL-2.0 2 3Problemas de hardware sob embargo 4================================= 5 6Escopo 7------ 8 9Problemas de hardware que resultam em problemas de segurança formam uma categoria 10de bugs de segurança diferente dos bugs de software puros que afetam apenas o 11kernel do Linux. 12 13Problemas de hardware como Meltdown, Spectre, L1TF, etc., devem ser tratados 14de maneira diferente porque geralmente afetam todos os Sistemas Operacionais ("OS") 15e, portanto, exigem coordenação entre diferentes fornecedores de SO, distribuições, 16fabricantes de silício, integradores de hardware e outras partes. Para alguns 17dos problemas, as mitigações de software podem depender de atualizações de 18microcódigo ou firmware, o que requer ainda mais coordenação. 19 20.. _pt_BR_Contact: 21 22Contato 23------- 24 25A equipe de segurança de hardware do kernel Linux é separada da equipe regular 26de segurança do kernel Linux. 27 28A equipe lida apenas com o desenvolvimento de correções para problemas de 29segurança de hardware sob embargo. Relatos de bugs de segurança de software puro 30no kernel Linux não são tratados por esta equipe, e o autor do relato será 31orientado a contatar a equipe regular de segurança do kernel Linux 32(:ref:`Documentation/admin-guide/ <securitybugs>`) em vez disso. 33 34A equipe pode ser contatada por e-mail em <hardware-security@kernel.org>. Esta 35é uma lista privada de oficiais de segurança que ajudarão você a coordenar uma 36correção de acordo com o nosso processo documentado. 37 38A lista é criptografada e o e-mail para a lista pode ser enviado criptografado 39por PGP ou S/MIME, e deve ser assinado com a chave PGP ou certificado S/MIME do 40autor do relato. A chave PGP e o certificado S/MIME da equipe estão disponíveis 41nas seguintes URLs: 42 43 - PGP: https://www.kernel.org/static/files/hardware-security.asc 44 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt 45 46Embora os problemas de segurança de hardware sejam frequentemente tratados pelo 47fabricante de silício afetado, nós acolhemos o contato de pesquisadores ou 48indivíduos que tenham identificado uma falha potencial de hardware. 49 50Oficiais de segurança de hardware 51^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 52 53A equipe atual de oficiais de segurança de hardware: 54 55 - Linus Torvalds (Fellow da Linux Foundation) 56 - Greg Kroah-Hartman (Fellow da Linux Foundation) 57 - Thomas Gleixner (Fellow da Linux Foundation) 58 59Operação das listas de e-mail 60^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 61 62As listas de e-mail criptografadas que são usadas em nosso processo são 63hospedadas na infraestrutura de TI da Linux Foundation. Ao fornecer este 64serviço, os membros da equipe de operações de TI da Linux Foundation têm, 65tecnicamente, a capacidade de acessar as informações sob embargo, mas são 66obrigados à confidencialidade por seu contrato de trabalho. O pessoal de TI 67da Linux Foundation também é responsável por operar e gerenciar o restante da 68infraestrutura do kernel.org. 69 70O atual diretor de infraestrutura de projetos de TI da Linux Foundation é 71Konstantin Ryabitsev. 72 73 74Acordos de não divulgação 75------------------------- 76 77A equipe de segurança de hardware do kernel Linux não é um órgão formal e, 78portanto, é incapaz de celebrar quaisquer acordos de não divulgação. A 79comunidade do kernel está ciente da natureza sensível de tais problemas e 80oferece um Memorando de Entendimento em vez disso. 81 82 83Memorando de Entendimento 84------------------------- 85 86A comunidade do kernel Linux compreende profundamente a necessidade de manter 87os problemas de segurança de hardware sob embargo para a coordenação entre 88diferentes fornecedores de SO, distribuidores, fabricantes de silício e outras 89partes. 90 91A comunidade do kernel Linux lidou com sucesso com problemas de segurança de 92hardware no passado e possui os mecanismos necessários para permitir o 93desenvolvimento compatível com a comunidade sob restrições de embargo. 94 95A comunidade do kernel Linux possui uma equipe dedicada de segurança de hardware 96para o contato inicial, que supervisiona o processo de tratamento de tais 97problemas sob as regras de embargo. 98 99A equipe de segurança de hardware identifica os desenvolvedores (especialistas no 100domínio) que formarão a equipe de resposta inicial para um problema específico. 101A equipe de resposta inicial pode trazer outros desenvolvedores (especialistas no 102domínio) para resolver o problema da melhor maneira técnica. 103 104Todos os desenvolvedores envolvidos comprometem-se a aderir às regras de embargo 105e a manter as informações recebidas em sigilo. A violação do compromisso levará à 106exclusão imediata do problema atual e à remoção de todas as listas de e-mail 107relacionadas. Além disso, a equipe de segurança de hardware também excluirá o 108infrator de futuros problemas. O impacto dessa consequência é um impedimento 109altamente eficaz em nossa comunidade. Caso ocorra uma violação, a equipe de 110segurança de hardware informará as partes envolvidas imediatamente. Se você ou 111qualquer outra pessoa tomar conhecimento de uma potencial violação, por favor, 112relate-a imediatamente aos oficiais de segurança de hardware. 113 114 115Processo 116^^^^^^^^ 117 118Devido à natureza globalmente distribuída do desenvolvimento do kernel Linux, 119reuniões presenciais são quase impossíveis para lidar com problemas de 120segurança de hardware. Conferências telefônicas são difíceis de coordenar devido 121a fusos horários e outros fatores, devendo ser usadas apenas quando estritamente 122necessário. O e-mail criptografado tem se mostrado o método de comunicação mais 123eficiente e seguro para esses tipos de problema. 124 125Início da divulgação 126""""""""""""""""""""" 127 128A divulgação começa enviando um e-mail para a equipe de segurança de hardware 129do kernel Linux, conforme a seção Contato acima. Este contato inicial deve 130conter uma descrição do problema e uma lista de qualquer silício afetado 131conhecido. Se a sua organização constrói ou distribui o hardware afetado, 132incentivamos você a considerar também quais outros hardwares podem ser 133afetados. A parte que faz a divulgação é responsável por contatar os 134fabricantes de silício afetados em tempo hábil. 135 136A equipe de segurança de hardware fornecerá uma lista de e-mail criptografada 137específica para o incidente, que será usada para a discussão inicial com o 138relator, divulgação posterior e coordenação de correções. 139 140A equipe de segurança de hardware fornecerá à parte divulgadora uma lista de 141desenvolvedores (especialistas no domínio) que devem ser informados inicialmente 142sobre o problema após confirmar com os desenvolvedores que eles aderirão a 143este Memorando de Entendimento e ao processo documentado. Esses desenvolvedores 144formam a equipe de resposta inicial e serão responsáveis por lidar com o 145problema após o contato inicial. A equipe de segurança de hardware apoia a 146equipe de resposta, mas não está necessariamente envolvida no processo de 147desenvolvimento de mitigações. 148 149Embora desenvolvedores individuais possam estar cobertos por um acordo de não 150divulgação por meio de seu empregador, eles não podem celebrar acordos 151individuais de não divulgação em seu papel como desenvolvedores do kernel 152Linux. No entanto, eles concordarão em aderir a este processo documentado e ao 153Memorando de Entendimento. 154 155A parte divulgadora deve fornecer uma lista de contatos para todas as outras 156entidades que já foram, ou devem ser, informadas sobre o problema. Isso serve 157a vários propósitos: 158 159 - A lista de entidades informadas permite a comunicação em toda a 160 indústria, por exemplo, outros fornecedores de SO, fornecedores de HW, etc. 161 162 - As entidades informadas podem ser contatadas para indicar especialistas 163 que devem participar do desenvolvimento da mitigação. 164 165 - Se um especialista necessário para lidar com um problema for funcionário 166 de uma entidade listada ou membro de uma entidade listada, as equipes de 167 resposta podem solicitar a inclusão desse especialista por parte daquela 168 entidade. Isso garante que o especialista também faça parte da equipe de 169 resposta da entidade. 170 171Divulgação 172"""""""""" 173 174A parte divulgadora fornece informações detalhadas à equipe de resposta inicial 175por meio da lista de e-mail criptografada específica. 176 177A partir de nossa experiência, a documentação técnica desses problemas costuma 178ser um ponto de partida suficiente, e esclarecimentos técnicos adicionais são 179melhor feitos por e-mail. 180 181Desenvolvimento de mitigações 182"""""""""""""""""""""""""""""" 183 184A equipe de resposta inicial configura uma lista de e-mail criptografada ou 185reaproveita uma já existente, se apropriado. 186 187O uso de uma lista de e-mail é próximo ao processo normal de desenvolvimento 188do Linux e tem sido usado com sucesso para desenvolver mitigações para vários 189problemas de segurança de hardware no passado. 190 191A lista de e-mail opera da mesma forma que o desenvolvimento normal do Linux. 192Os patches são publicados, discutidos, revisados e, se aprovados, aplicados a 193um repositório git não público que é acessível apenas aos desenvolvedores 194participantes por meio de uma conexão segura. O repositório contém o ramo 195(branch) principal de desenvolvimento contra o kernel mainline e ramos de 196retroporte (backport) para versões estáveis do kernel conforme necessário. 197 198A equipe de resposta inicial identificará outros especialistas da comunidade 199de desenvolvedores do kernel Linux conforme necessário. Qualquer parte 200envolvida pode sugerir a inclusão de outros especialistas, cada um dos quais 201estará sujeito aos mesmos requisitos descritos acima. 202 203A inclusão de especialistas pode ocorrer a qualquer momento no processo de 204desenvolvimento e precisa ser tratada em tempo hábil. 205 206Se um especialista for funcionário ou membro de uma entidade na lista de 207divulgação fornecida pela parte divulgadora, a participação será solicitada 208à entidade relevante. 209 210Caso contrário, a parte divulgadora será informada sobre a participação 211dos especialistas. Os especialistas são cobertos pelo Memorando de Entendimento 212e a parte divulgadora é solicitada a reconhecer a participação deles. No caso 213de a parte divulgadora ter um motivo convincente para se opor, qualquer 214objeção deve ser levantada no prazo de cinco dias úteis e resolvida com a 215equipe do incidente imediatamente. Se a parte divulgadora não reagir dentro 216de cinco dias úteis, isso é considerado como reconhecimento tácito. 217 218Após a equipe do incidente reconhecer ou resolver uma objeção, o especialista 219é informado e integrado ao processo de desenvolvimento. 220 221Os participantes da lista não podem se comunicar sobre o problema fora da 222lista de e-mail privada. Os participantes da lista não podem usar nenhum 223recurso compartilhado (por exemplo, fazendas de compilação do empregador, 224sistemas de IC, etc.) ao trabalhar em patches. 225 226Acesso antecipado 227""""""""""""""""" 228 229Os patches discutidos e desenvolvidos na lista não podem ser distribuídos a 230nenhum indivíduo que não seja membro da equipe de resposta, nem a nenhuma outra 231organização. 232 233Para permitir que os fornecedores de silício afetados trabalhem com suas equipes 234internas e parceiros da indústria em testes, validação e logística, a seguinte 235exceção é fornecida: 236 237 Representantes designados dos fornecedores de silício afetados têm permissão 238 para repassar os patches a qualquer momento para a equipe de resposta do 239 fornecedor de silício. O representante deve notificar a equipe de resposta 240 do kernel sobre o repasse. O fornecedor de silício afetado deve possuir e 241 manter seu próprio processo de segurança documentado para quaisquer patches 242 compartilhados com sua equipe de resposta que seja consistente com esta 243 política. 244 245 A equipe de resposta do fornecedor de silício pode distribuir esses patches 246 aos seus parceiros da indústria e às suas equipes internas sob o processo 247 de segurança documentado do fornecedor de silício. O feedback dos parceiros 248 da indústria retorna ao fornecedor de silício e é comunicado por ele à 249 equipe de resposta do kernel. 250 251 O repasse para a equipe de resposta do fornecedor de silício remove 252 qualquer responsabilidade civil ou legal da equipe de resposta do kernel 253 em relação à divulgação prematura que ocorra devido ao envolvimento das 254 equipes internas ou parceiros da indústria do fornecedor de silício. O 255 fornecedor de silício garante esta liberação de responsabilidade ao 256 concordar com este processo. 257 258Lançamento coordenado 259""""""""""""""""""""" 260 261As partes envolvidas negociarão a data e a hora em que o embargo termina. Nesse 262ponto, as mitigações preparadas são publicadas nas árvores de kernel relevantes. 263Não há processo de pré-notificação: as mitigações são publicadas publicamente e 264disponibilizadas para todos ao mesmo tempo. 265 266Embora entendamos que problemas de segurança de hardware exijam tempo de embargo 267coordenado, o tempo de embargo deve ser restrito ao mínimo necessário para que 268todas as partes envolvidas desenvolvam, testem e preparem suas mitigações. 269Estender o tempo de embargo artificialmente para cumprir datas de palestras em 270conferências ou outros motivos não técnicos cria mais trabalho e ônus para os 271desenvolvedores e equipes de resposta envolvidos, pois os patches precisam ser 272mantidos atualizados para acompanhar o desenvolvimento contínuo do kernel 273upstream, o que pode criar alterações conflitantes. 274 275Atribuição de CVE 276"""""""""""""""""" 277 278Nem a equipe de segurança de hardware nem a equipe de resposta inicial atribuem 279CVEs, nem os CVEs são necessários para o processo de desenvolvimento. Se os CVEs 280forem fornecidos pela parte divulgadora, eles poderão ser usados para fins de 281documentação. 282 283Embaixadores do processo 284------------------------ 285 286Para obter assistência com este processo, estabelecemos embaixadores em várias 287organizações, que podem responder a perguntas sobre ou fornecer orientações 288acerca do processo de relatórios e tratamento posterior. Os embaixadores não 289estão envolvidos na divulgação de um problema específico, a menos que seja 290solicitado por uma equipe de resposta ou por uma parte divulgada envolvida. 291A lista atual de embaixadores: 292 293 ============= ======================================================== 294 AMD Tom Lendacky <thomas.lendacky@amd.com> 295 Ampere Darren Hart <darren@os.amperecomputing.com> 296 ARM Catalin Marinas <catalin.marinas@arm.com> 297 IBM Power Madhavan Srinivasan <maddy@linux.ibm.com> 298 IBM Z Christian Borntraeger <borntraeger@de.ibm.com> 299 Intel Tony Luck <tony.luck@intel.com> 300 Qualcomm Trilok Soni <quic_tsoni@quicinc.com> 301 RISC-V Palmer Dabbelt <palmer@dabbelt.com> 302 Samsung Javier González <javier.gonz@samsung.com> 303 304 Microsoft James Morris <jamorris@linux.microsoft.com> 305 Xen Andrew Cooper <andrew.cooper3@citrix.com> 306 307 Canonical John Johansen <john.johansen@canonical.com> 308 Debian Ben Hutchings <ben@decadent.org.uk> 309 Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 310 Red Hat Josh Poimboeuf <jpoimboe@redhat.com> 311 SUSE Jiri Kosina <jkosina@suse.cz> 312 313 Google Kees Cook <keescook@chromium.org> 314 315 LLVM Nick Desaulniers <ndesaulniers@google.com> 316 ============= ======================================================== 317 318Se você quiser que sua organização seja adicionada à lista de embaixadores, 319entre em contato com a equipe de segurança de hardware. O embaixador indicado 320deve compreender e apoiar totalmente o nosso processo e, idealmente, estar bem 321conectado na comunidade do kernel Linux. 322 323Listas de e-mail criptografadas 324------------------------------- 325 326Usamos listas de e-mail criptografadas para comunicação. O princípio de 327operação dessas listas é que o e-mail enviado para a lista é criptografado 328com a chave PGP da lista ou com o certificado S/MIME da lista. O software 329da lista de e-mail descriptografa o e-mail e o recriptografa individualmente 330para cada assinante com a chave PGP ou certificado S/MIME do assinante. 331Detalhes sobre o software da lista de e-mail e a configuração usada para 332garantir a segurança das listas e a proteção dos dados podem ser encontrados 333aqui: https://korg.wiki.kernel.org/userdoc/remail. 334 335Listas de chaves 336^^^^^^^^^^^^^^^^ 337 338Para o contato inicial, consulte a seção :ref:`pt_BR_Contact` acima. Para listas de 339e-mail específicas de incidentes, a chave e o certificado S/MIME são transmitidos 340aos assinantes por e-mail enviado a partir da lista específica. 341 342Inscrição em listas específicas de incidentes 343^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 344 345A inscrição em listas específicas de incidentes é gerenciada pelas equipes de 346resposta. As partes informadas que desejam participar da comunicação enviam 347uma lista de potenciais especialistas para a equipe de resposta, para que esta 348possa validar as solicitações de inscrição. 349 350Cada assinante precisa enviar uma solicitação de inscrição para a equipe de 351resposta por e-mail. O e-mail deve estar assinado com a chave PGP ou o certificado 352S/MIME do assinante. Se uma chave PGP for utilizada, ela deve estar disponível 353em um servidor de chaves público e, idealmente, conectada à teia de confiança 354(web of trust) PGP do kernel Linux. Veja também: 355https://www.kernel.org/signature.html. 356 357A equipe de resposta verifica se a solicitação do assinante é válida e o 358adiciona à lista. Após a inscrição, o assinante receberá e-mails da lista de 359e-mail que são assinados com a chave PGP da lista ou com o certificado S/MIME 360da lista. O cliente de e-mail do assinante pode extrair a chave PGP ou o 361certificado S/MIME da assinatura para que o assinante possa enviar e-mails 362criptografados para a lista.