Dual boot no Linux e Windows em tempos de Secure Boot e UEFI

Acabo de passar por dificuldades ao tentar fazer um sistema com dual boot com Linux e Windows, e relato aqui esta experiência, junto a um conjunto de dicas sobre como contornar a situação de forma mais eficiente, rápida e indolor. Fazer dual boot Linux-Windows já foi muito mais simples!

Estou voltando a acompanhar o Linux, depois de vários anos afastado do uso. Da lá para cá algumas tecnologias de hardware e firmware foram introduzidas, e é bom estar ciente de como elas podem tornar o processo de dual boot mais complicado. Faz uns 3 ou 4 meses que instalei o Ubuntu 16.04 LTS em um dos meus PCs, que desde então tenho usado como a máquina principal, e agora queria instalar o 17.10 em uma outra máquina na qual ainda uso o Windows 7 por questões de compatibilidade. A forma como sempre preferi fazer dual boot foi instalar o Linux em um HD separado, controlando o boot manager, e não mexer no HD de instalação do Windows. No final eu entrava nos arquivos de configuração do GRUB e adicionava a entrada do Windows. Pois bem, meu erro crucial foi achar que nas novas motherboards, que implementam BIOS com UEFI e Secureboot, este procedimento seria o mesmo. No final das contas, algo que eu costumava fazer em meia hora durou a tarde inteira, entrando pela noite... mas não precisa ser assim, se forem tomados alguns cuidados.

A informação está toda na Web, só que espalhada, vinculada a sistemas específicos (a placa mãe, a distro linux, a versão do Windows), e nem sempre fica claro o que é opcional. Por isso resolvi fazer um conjunto de dicas mais genéricas num formato de checklist, e ressaltando os pontos de atenção essenciais, de modo a orientar o usuário de qualquer desses sistemas, que depois se necessário poderá procurar os detalhes para um modelo específico. Entre esses usuários possivelmente estarei eu no futuro, muita coisa desse blog eu documento para mim mesmo :-). E várias vezes realmente consultei depois. É importante notar que a solução descrita abaixo implica em desabilitar o Secure Boot, e caso haja alguma restrição quanto a isso outra opção deve ser buscada.

Pressuposto: um PC com BIOS mais novo, usando UEFI, um HD com Windows instalado, a partir da versão 7, um HD vazio (ou a ser apagado) para instalar o Linux em dual boot. A instalação do Windows não deve ser mexida e o controle de boot manager irá ficar no Linux.

No meu caso específico foram usados uma placa mãe Asus Sabertooth 990FX R2.0, Windows 7 e Ubuntu 17.10. Você vai precisar também da mídia de instalação do Windows, no meu caso o DVD original do Windows 7,  a mídia de instalação do Linux, obviamente, um pendrive vazio para backup das chaves do Secure Boot, e é bom ter também um pendrive live do gparted para corrigir algum erro e recomeçar rapidamente.

Vamos ao checklist:

1. Verifique se o Secure boot está habilitado na sua placa mãe, e se estiver, desabilite. Provavelmente estará, pois costuma vir assim por default. Ao desabilitar o Securom deve-se salvar antes as chaves para poder reabilitar no futuro, para isso deve ser usado o pendrive vazio. No artigo linkado nas fontes deste post, no final, é mostrado o procedimento para o BIOS da Asus semelhante ao meu. O procedimento é semelhante em outras placas mãe, mas caso não seja tão evidente no seu BIOS necessário buscar manual, na Web, etc.

2. Verifique se a partição de instalação do Windows está no modo GPT. Confesso que depois de instalar Windows centenas de vezes nunca tinha prestado atenção nisso. Neste ponto é que será necessária a mídia de instalação do Windows, entrar no modo console (shift+F10 na tela inicial da instalação) e fazer a conversão, se necessário. No meu caso, depois de tudo dar errado e eu passar a  procurar os culpados, verifiquei que a partição do Windows já estava no modo GPT, aparece um asterisco na coluna "gpt" ao listar a partição (comando "diskpart", e depois "list disk"). Ao que parece este deve ser o default das instalações atuais, pois como falei, nunca havia considerado isso antes. Provavelmente não será preciso fazer nada, ainda assim, como esta foi a situação de sucesso, considerei importante incluir este item. Se não estiver como GPT devem ser usado os comandos:

select disk <número do disco que aparece no list disk>
clean
convert gpt
exit
O mesmo link citado antes também cobre esta parte, mas já reproduzi quase tudo aí acima.

3. Instale o Linux no HD vazio. Aqui algumas precauções devem ser tomadas. Normalmente antes eu instalava o Linux até desconectando o HD do Windows, para garantir que não seria alterado. Mas ao instalar o Ubuntu 17.10 com o HD do Windows 7 plugado, no momento oportuno da instalação ele avisa que existe um outros sistemas não-UEFI (em modo BIOS) e que caso se instale o Ubuntu com boot UEFI poderá haver dificuldade para boot do outro sistema. Isto é uma grande facilidade, e ao ver esta mensagem basta voltar e se certificar de não instalar o Linux em modo UEFI. O resto da instalação é normal. O resultado deste passo é que todos os sistemas instalados no PC não serão com boot UEFI.

4. Verifique se na ordem de boot o HD com o Linux tem prioridade. Basta reiniciar pelo BIOS e verificar, caso necessário alterar a ordem. Como é a instalação do Linux é que vai gerenciar o menu de boot, segundo o pressuposto no início, ele tem que entrar primeiro. Aqui vale um elogio ao Ubuntu, que agora já coloca uma entrada no menu do GRUB para direcionar direto para o Setup do BIOS. Se ao reiniciar a primeira vez depois de instalar o Linux ele entrar no Windows, é por causa desta ordem errada (nem seria preciso dizer que as midias de instalação do Windows e Linux a esta altura já deveriam ter sido removidas...).

5. Verificar a entrada no Windows no menu do GRUB. O Ubuntu agora já detecta e insere o Windows automáticamente, e quando não o faz e por causa de falha em um dos itens acima. Tradicionalmente eu fazia as alterações na mão, e na realidade neste ponto ficou mais fácil, ou seja, tomadas as precauções, o processo acaba não sendo tão desgastante. Se a sua distro não incluir a entrada automaticamente será preciso alterar a configuração de boot editando os arquivos. No GRUB é o arquivo "40_custom" que fica em "\etc\grub.d\", e depois deve-se usar o comando "update-grub". Se o menu do GRUB não estiver aparecendo durante o boot, olhar a configuração dos timeouts no arquivo "\etc\default\grub". Atenção, antes de sair editando arquivos execute uma ou duas inicializações normais (sem erros) do sistema Linux. Comigo só apareceu no segundo boot, e na tentativa final de sucesso não precisei editar os arquivos do GRUB. 

Conclusão

Resumindo, a forma de conviver com o Secure boot e UEFI e ainda poder fazer dual boot é evitar os primeiros. Na realidade eu não busquei a alternativa para compatibilizar as duas coisas. Quando os BIOS UEFI foram lançados li vários artigos sobre as vantagens técnicas e de segurança desta nova tecnologia, embora ficando com a impressão que vinha para resolver problemas que eu não tinha. No entanto ao seguir o procedimento acima é importante estar consciente de se estar anulando estas melhorias.  

Fontes:
[1]  https://www.technorms.com/45538/disable-enable-secure-boot-asus-motherboard-uefi-bios-utility

[2] Artigo na Wikipedia sobre UEFI e Secure Boot
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

Acompanhando o caso da falha de segurança nos processadores Intel

Há mais ou menos uma semana temos acompanhado as notícias sobre uma grave falha de segurança em processadores Intel, que permitiria acesso a dados sigilosos do usuário a qualquer programa rodando na máquina ou mesmo código Javascript no browser. Não é o primeiro caso deste tipo, e não será o último, ainda assim é chocante perceber a abrangência do problema e como algo deste tipo vai se repetindo. 

Desde então foram surgindo artigos na mídia especializada em tecnologia, com muita coisa parecendo inconsistente, contraditória  e superficial.  Isto é típico e já deve ser sempre levado em conta (na maioria são jornalistas). Embora esta cobertura da imprensa pelo menos tenha o mérito de chamar atenção para o problema, quando se tenta entendê-lo de fato, avaliar os riscos e tomar decisões, fica claro que é insuficiente e pode facilmente induzir ao erro.

O intuito deste post não é esclarecer todos os pontos associados a esta falha, até porque no momento não tenho todas as fontes suficientes pra isso, e nem ficar jogando mais lenha nessa fogueira de desinformação citada acima. Vou apenas listar alguns pontos que merecem atenção, compilar alguns artigos que considerei mais confiáveis. Em muitos casos ficam registradas as dúvidas geradas pela cobertura da imprensa especializada e também pelas declarações da própria indústria envolvida, que na maioria dos casos também tem interesse em ocultar ou amenizar o problema, por motivos obvios. Será necessário uma pesquisa posterior para esclarecer alguns, quando necessário ou se for de interesse particular.

1. Abrangência

Pela descrição a falha é extremamente grave, inicialmente se falando de "todos os processadores Intel nos últimos 10 anos". Outros artigos falam que também afeta os processadores AMD e ARM. A AMD em nota declarou que a falha não afeta seus componentes, e também neste post. A questão aqui é que pode não ser exatamente o mesmo bug e sim dois deles, ou uma variação especifica. (Update 5/1/2018: e fato, pela última informação são duas vulnerabilidades, Spectre e Meltdown, sendo que a primeira afeta também AMD e ARM). Cabe pesquisar melhor antes de sair trocando todos os processadores por AMD, até porque um patch de software (para contornar o problema de hardware/firmware) está ou disponível, no Linux,  ou a caminho, no Windows. Ao contrário do que foi dito em alguns canais, o problema afeta tanto processadores de servidores quanto de PCs e outros dispositivos clients.

O cenário de ataque inclui um programa malicioso rodando na máquina, o que demandaria que um usuário executasse localmente tal programa, mas alguns artigos já falam em  Javascript no browser, o que aumenta em muito o risco (por sinal ultimamente Javascript tem sido associado a outras vulnerabilidades, incluindo o caso da mineração involuntária de criptomoedas em sites, e já começo a achar que javascript em browsers não foi uma boa idéia afinal...) .

2. A correção

Dado que o erro é no projeto do processador, a solução direta seria a atualização dele, e como até onde eu sei não se pode alterar o microcódigo de um processador, seria uma troca física do componente. Isso demandaria o descarte no bilhões de dolares em hardware no mundo todo (os processadores, as placas mãe compatíveis com eles, etc.). Creio que ninguém cogita isso, e a solução será uma mudança nos sistemas operacionais para impedir o acesso à vulnerabilidade. Alguns artigos citam que seria necessária uma alteração no firmware também. Não ficou claro se estava se referindo à BIOS [Update 20/01/2018: a atualização da BIOS é sim necessária, já fiz em um dos meus PCs, mas infelizmente não está disponível para os mais antigos. Ver nas fontes o link para a página de updades de BIOS da Asus]. Como dito no item anterior, o patch está disponível, no Linux,  ou a caminho, no Windows, prevista para a atualização mensal de segurança de 9/1/2018, próxima terça. [Update 5/1/2016: O patch para Windows 10 já está disponível, trata-se do KB4056892. Nada foi dito sobre o Windows 7 e 8, que ainda estão com suporte de segurança]. Atenção que, quando se diz que está disponível no Linux não quer dizer que já esteja na sua distribuição, ou na sua instalação. Os administradores da sua distribuição terão que disponibilizar o pacote de patch nos repositórios de atualização. E obviamente o adminisrtrador da máquina terá que ter configurado as atualizações automáticas ou instalado manualmente.

Um fato que está preocupando muitos usuários é a informação de que o redesenho da segurança do Linux e Windows necessário no patch irá levar a uma queda de desenpenho de 5 a 30% no processador. Ou seja, um downgrade imediato e não esperado, o que para alguns usuário pode passar despercebido, mas para outros que dependem dessa performance (profissionais da área de vídeo, processamento numérico científico, gamers, etc) ou estão no limite do processador, pode ser um desastre. Para saber com certeza só rodando os benchmarks relevantes para o seu padrão de uso no seu PC agora, antes do patch, e depois.

Além dos usuários individuais, toda a industria de serviços em nuvem (Microsoft Azure, Amazon AWS, etc) será afetada, pois eles vendem basicamente poder de processamento. De um momento para outro o recurso vendido disponível será menor. É esperar pra ver o impacto disso.

Meu caso prático real, tenho PCs Windows e Linux, e mesmo no caso do linux Ubuntu 16.04 LTS não tenho certeza se a correção já foi implementada, pois deste então tenho tentado ler os detalhes das atualizações que estão sendo aplicadas e não há esta informação. Seria necessária mais pequisa nos foruns dos desenvolvedores. Procurei no portal do Ubuntu e da canonical e não achei (pode até estar lá mais não encontrei). Esta informação poderia ser mais acessível, dando mais segurança e tranquilidade aos usuários.

3. O que fazer enquanto isso

Os patchs de software resolverão o problema, a questão neste momento é primeiro saber se tendo Linux ela já esta implementada na sua distro, e no caso no Windows esperar atá o dia 9 de janeiro (este artigo está sendo escrito no dia 4). 

Enquanto isso só se pode evitar as situações de risco. A instalação ou execução de qualquer programa de fonte não reconhecida, ou acesso a qualquer website suspeito, o que implicaria na realidade conhecer a idoneidade de qualquer site apontado por algum link quando se está navegando, o que é impossível, então o único conselho prático é limitar a navegação web ao mínimo... muito radical?  

4. Conclusões

A conclusão que eu tiro disso tudo é que estes incidentes se repetem e são praticamente inevitáveis. Não é como se a partir de agora as empresas de hardware e software irão tomar mais cuidado e melhorar as áreas de controle de qualidade para evitar que casos assim ocorram novamente. Eles podem até fazer isso, o que não evitará totalmente. Basta analisar a história e levar em consideração que a complexidade desses sistemas é grande e tende a aumentar. Os usuários estarão sempre expostos a uma ocorrência deste tipo, e geralmente sem a informação necessária para se proteger.

Fontes:

[1] https://meltdownattack.com/meltdown.pdf

[2] https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

[3] https://lkml.org/lkml/2017/12/27/2

[4] https://www.theverge.com/2018/1/3/16846540/intel-processor-security-flaw-bug-response

[5] https://www.theverge.com/2018/1/3/16846784/microsoft-processor-bug-windows-10-fix

[6] https://gizmodo.com/what-we-know-so-far-about-meltdown-and-spectre-the-dev-1821759062

[7] https://www.cnet.com/how-to/how-to-protect-your-pc-against-the-intel-chip-flaw/

[8] https://support.microsoft.com/pt-br/help/4056892/windows-10-update-kb4056892

[9] [Update 20/01/2018: Atualizaçào de BIOS para as placas mãe Asus com processador Intel de 6a., 7a. e 8a. gerações, que atualiza o microcódigo do processador: 

https://www.asus.com/News/V5urzYAT6myCC1o2
Fiz o update para a BIOS 1203 da placa ROG MAXIMUS IX APEX ]

[10] Correção por hardware nas próximas gerações, segundo Intel:
http://www.hardware.com.br/noticias/2018-01/solucao-via-hardware-contra-meltdown-spectre-sera-adotada-pela-intel-nas-proximas-geracoes.html