{"id":123002,"date":"2025-03-26T04:22:53","date_gmt":"2025-03-26T02:22:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/razrabotchiki-grub2-rassmatrivayut-vozmozhnost-ispolzovaniya-yazyka-rust"},"modified":"2025-03-26T04:22:53","modified_gmt":"2025-03-26T02:22:53","slug":"razrabotchiki-grub2-rassmatrivayut-vozmozhnost-ispolzovaniya-yazyka-rust","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/razrabotchiki-grub2-rassmatrivayut-vozmozhnost-ispolzovaniya-yazyka-rust","title":{"rendered":"Os desenvolvedores do GRUB2 est\u00e3o considerando o uso da linguagem Rust","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Vladimir Serbinenko, um dos tr\u00eas mantenedores do carregador GRUB2, que fez mais de cinco mil altera\u00e7\u00f5es na base de c\u00f3digo, prop\u00f4s a discuss\u00e3o sobre a possibilidade de escrever m\u00f3dulos para o GRUB2 usando a linguagem Rust. Vladimir apresentou os primeiros resultados de experimentos com a adi\u00e7\u00e3o de suporte a Rust no GRUB2 e a cria\u00e7\u00e3o das bibliotecas necess\u00e1rias. Para o GRUB, tamb\u00e9m foram preparadas altera\u00e7\u00f5es que permitem o uso de bibliotecas compartilhadas ('.so', ET_DYN) para m\u00f3dulos, em vez de vincul\u00e1-los no n\u00edvel de arquivos objeto ('.o', ET_REL). <\/p>\n
A iniciativa ainda est\u00e1 sendo posicionada como um experimento separado, que n\u00e3o afetar\u00e1 o desenvolvimento do GRUB2. O uso ideal do Rust no GRUB menciona a escrita de m\u00f3dulos para novos sistemas de arquivos. N\u00e3o se descarta a reescrita em Rust do c\u00f3digo para trabalhar com parti\u00e7\u00f5es de disco e GPT. <\/p>\n
Espera-se que o uso do Rust ajude o projeto a reduzir a probabilidade de alguns tipos de erros, especialmente no c\u00f3digo dos m\u00f3dulos, que cont\u00eam v\u00e1rias grandes e complexas rotinas de an\u00e1lise. Em fevereiro, durante uma auditoria na base de c\u00f3digo do GRUB, foram identificados 72 problemas de seguran\u00e7a, dos quais 21 foram considerados vulnerabilidades perigosas, adequadas para contornar o mecanismo de verifica\u00e7\u00e3o de inicializa\u00e7\u00e3o UEFI Secure Boot. 20 das 21 vulnerabilidades foram causadas por erros no manuseio da mem\u00f3ria, levando a estouros de buffer ou acesso \u00e0 mem\u00f3ria ap\u00f3s a libera\u00e7\u00e3o. <\/p>\n
Al\u00e9m disso, pode-se observar o lan\u00e7amento do projeto GNU Boot 0.1 RC6, que incluiu as corre\u00e7\u00f5es de vulnerabilidades mencionadas acima (no pr\u00f3prio GRUB2, as corre\u00e7\u00f5es continuam sendo disseminadas na forma de patches sem a cria\u00e7\u00e3o de uma vers\u00e3o separada). O projeto GNU Boot desenvolve uma alternativa \u00e0s firmwares propriet\u00e1rias UEFI e BIOS, baseada no CoreBoot, mas aplicando requisitos mais r\u00edgidos para incluir componentes bin\u00e1rios. O GNU Boot \u00e9 apresentado como 'coreboot-libre', ou seja, como uma vers\u00e3o do CoreBoot livre de blobs e componentes n\u00e3o livres, assim como o projeto Linux-libre desenvolve uma vers\u00e3o limpa do kernel Linux. Projetos semelhantes como Libreboot e Canoeboot tamb\u00e9m est\u00e3o em desenvolvimento. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"