{"id":104123,"date":"2022-05-23T15:36:40","date_gmt":"2022-05-23T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-yadra-linux-5-18"},"modified":"2022-05-23T15:36:40","modified_gmt":"2022-05-23T13:36:40","slug":"reliz-yadra-linux-5-18","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/reliz-yadra-linux-5-18","title":{"rendered":"Lan\u00e7amento do n\u00facleo Linux 5.18","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s dois meses de desenvolvimento, Linus Torvalds lan\u00e7ou o kernel Linux 5.18. Entre as mudan\u00e7as mais not\u00e1veis est\u00e3o: uma grande limpeza de funcionalidades obsoletas, a declara\u00e7\u00e3o de obsolesc\u00eancia do sistema de arquivos Reiserfs, a implementa\u00e7\u00e3o de eventos de rastreamento de processos de usu\u00e1rio, a adi\u00e7\u00e3o de suporte ao mecanismo de bloqueio de execu\u00e7\u00e3o de exploits Intel IBT, a inclus\u00e3o de um modo de detec\u00e7\u00e3o de estouro de buffer ao usar a fun\u00e7\u00e3o memcpy(), a adi\u00e7\u00e3o de um mecanismo de rastreamento de chamadas de fun\u00e7\u00e3o fprobe, a melhoria no desempenho do escalonador de tarefas em CPUs AMD Zen, inclus\u00e3o de um driver para gerenciar funcionalidades da CPU Intel (SDS), e integra\u00e7\u00e3o de partes de patches para reestrutura\u00e7\u00e3o de arquivos de cabe\u00e7alho, al\u00e9m da aprova\u00e7\u00e3o do uso do padr\u00e3o C11. <\/p>\n
A nova vers\u00e3o inclui 16206 corre\u00e7\u00f5es feitas por 2127 desenvolvedores (na vers\u00e3o anterior, havia 14203 corre\u00e7\u00f5es feitas por 1995 desenvolvedores). O tamanho do patch \u00e9 de 108 MB (as mudan\u00e7as afetaram 14235 arquivos, foram adicionadas 1340982 linhas de c\u00f3digo e removidas 593836 linhas). Cerca de 44% de todas as mudan\u00e7as apresentadas na vers\u00e3o 5.18 est\u00e3o relacionadas aos drivers de dispositivos, aproximadamente 16% das mudan\u00e7as dizem respeito \u00e0 atualiza\u00e7\u00e3o de c\u00f3digo espec\u00edfico para arquiteturas de hardware, 11% est\u00e3o ligadas \u00e0 pilha de rede, 3% \u00e0s sistemas de arquivos e 3% a subsistemas internos do n\u00facleo. <\/p>\n
Principais novidades no kernel 5.18: <\/p>\n
\n
Subsistema de disco, entrada\/sa\u00edda e sistemas de arquivos<\/b>\n
\n
No sistema de arquivos Btrfs, foi adicionada a capacidade de passar dados comprimidos durante a execu\u00e7\u00e3o das opera\u00e7\u00f5es send e receive. Anteriormente, ao usar send\/receive, o lado que enviava descompactava os dados armazenados de forma comprimida, enquanto o lado receptor recompunha os dados antes da grava\u00e7\u00e3o. No kernel 5.18, aplicativos no espa\u00e7o do usu\u00e1rio que usam chamadas send\/receive agora t\u00eam a capacidade de transmitir dados comprimidos sem reempacotamento. A funcionalidade foi implementada gra\u00e7as \u00e0s novas opera\u00e7\u00f5es ioctl BTRFS_IOC_ENCODED_READ e BTRFS_IOC_ENCODED_WRITE, que permitem ler e gravar informa\u00e7\u00f5es diretamente em extens\u00f5es.\n
Al\u00e9m disso, no Btrfs, o desempenho do fsync foi melhorado. Foi adicionada a capacidade de deduplica\u00e7\u00e3o e execu\u00e7\u00e3o de reflink (clonagem de metadados de arquivo criando um link para dados j\u00e1 existentes sem a necessidade de c\u00f3pia real) para todo o armazenamento, sem limita\u00e7\u00f5es a pontos de montagem. <\/p>\n
No modo de entrada\/sa\u00edda direta (Direct I\/O), \u00e9 poss\u00edvel acessar arquivos criptografados ao usar a criptografia inline do fscrypt, na qual as opera\u00e7\u00f5es de criptografia e a descriptografia s\u00e3o realizadas pelo controlador de armazenamento, e n\u00e3o pelo n\u00facleo. Com a criptografia convencional baseada no n\u00facleo, o acesso a arquivos criptografados por meio do Direct I\/O continua a ser imposs\u00edvel, pois o acesso aos arquivos \u00e9 feito evitando o mecanismo de buffer no n\u00facleo.\n
O servidor NFS agora tem suporte padr\u00e3o para o protocolo NFSv3, que n\u00e3o requer ativa\u00e7\u00e3o separada e est\u00e1 dispon\u00edvel com a ativa\u00e7\u00e3o geral do NFS. O NFSv3 \u00e9 considerado a vers\u00e3o principal e sempre suportada do NFS, enquanto o suporte ao NFSv2 pode ser descontinuado no futuro. A efici\u00eancia da leitura do conte\u00fado dos diret\u00f3rios foi significativamente aumentada.\n
O sistema de arquivos ReiserFS foi classificado como obsoleto e est\u00e1 programado para remo\u00e7\u00e3o em 2025. A classifica\u00e7\u00e3o do ReiserFS como obsoleto permitir\u00e1 reduzir o esfor\u00e7o de manuten\u00e7\u00e3o de altera\u00e7\u00f5es comuns entre sistemas de arquivos relacionadas ao suporte de uma nova API para montagem, iomap e blobs.\n
Para o sistema de arquivos F2FS, foi implementada a possibilidade de mapeamento de identificadores de usu\u00e1rios em sistemas de arquivos montados, utilizado para associar arquivos de um determinado usu\u00e1rio em uma parti\u00e7\u00e3o montada de outro usu\u00e1rio no sistema atual.\n
O c\u00f3digo para contagem de estat\u00edsticas nos manipuladores do Device-mapper foi reestruturado, o que aumentou significativamente a precis\u00e3o da contabiliza\u00e7\u00e3o em manipuladores como o dm-crypt.\n
Para dispositivos NVMe, foi implementado suporte para somas de verifica\u00e7\u00e3o de 64 bits para a verifica\u00e7\u00e3o de integridade.\n
Para o sistema de arquivos exfat, foi proposta uma nova op\u00e7\u00e3o de montagem chamada 'keep_last_dots', que pro\u00edbe a remo\u00e7\u00e3o de pontos no final do nome do arquivo (no Windows, os pontos no final do nome s\u00e3o removidos por padr\u00e3o).\n
No EXT4, a performance do modo fast_commit foi melhorada e a escalabilidade aumentada. A op\u00e7\u00e3o de montagem 'mb_optimize_scan', que melhora a performance em condi\u00e7\u00f5es de grande fragmenta\u00e7\u00e3o do sistema de arquivos, foi adaptada para funcionar com arquivos com extens\u00f5es.\n
O suporte para streams de grava\u00e7\u00e3o (write stream) foi interrompido no subsistema que gerencia dispositivos de bloco. Esse recurso foi proposto para SSDs, mas n\u00e3o se espalhou e atualmente n\u00e3o existem dispositivos que suportem este modo, sendo improv\u00e1vel que eles apare\u00e7am no futuro. <\/ul>\n
Mem\u00f3ria e servi\u00e7os do sistema<\/b>\n
\n
Foi iniciada a integra\u00e7\u00e3o de um conjunto de patches que permite reduzir significativamente o tempo de recompila\u00e7\u00e3o do n\u00facleo, reestruturando a hierarquia dos arquivos de cabe\u00e7alho e diminuindo o n\u00famero de depend\u00eancias cruzadas. O n\u00facleo 5.18 inclui patches que otimizam a estrutura dos arquivos de cabe\u00e7alho do escalonador de tarefas (kernel\/sched). Comparado \u00e0 vers\u00e3o anterior, o consumo de tempo do processador na compila\u00e7\u00e3o do c\u00f3digo kernel\/sched foi reduzido em 61%, enquanto o tempo real diminuiu em 3,9% (de 2,95 para 2,84 segundos).\n
No c\u00f3digo do n\u00facleo, o uso do padr\u00e3o C11, publicado em 2011, foi permitido. Anteriormente, o c\u00f3digo adicionado ao n\u00facleo deveria estar de acordo com a especifica\u00e7\u00e3o ANSI C (C89), estabelecida em 1989. Nos scripts de constru\u00e7\u00e3o do n\u00facleo 5.18, a op\u00e7\u00e3o '--std=gnu89' foi substitu\u00edda por '--std=gnu11 -Wno-shift-negative-value'. A possibilidade de usar o padr\u00e3o C17 foi considerada, mas nesse caso seria necess\u00e1rio aumentar a vers\u00e3o m\u00ednima suportada do GCC; no entanto, a inclus\u00e3o do suporte ao C11 se enquadra nos requisitos atuais para a vers\u00e3o do GCC (5.1).\n
A efici\u00eancia do escalonamento de tarefas em processadores AMD com microarquitetura Zen foi aumentada, onde cada n\u00f3 com canais de mem\u00f3ria locais possui m\u00faltiplos caches de \u00faltimo n\u00edvel (LLC, Last Level Cache). Na nova vers\u00e3o, o desbalanceamento de LLC entre n\u00f3s NUMA foi corrigido, resultando em um aumento significativo de desempenho sob certas cargas de trabalho.\n
Foram ampliados os recursos para rastreamento de aplicativos no espa\u00e7o do usu\u00e1rio. Na nova vers\u00e3o do n\u00facleo, foi adicionada a possibilidade de que processos de usu\u00e1rios criem eventos de rastreamento (User events) e gravar dados em um buffer de rastreamento, que podem ser visualizados atrav\u00e9s de utilit\u00e1rios t\u00edpicos de rastreamento do n\u00facleo, como ftrace e perf. Os eventos de rastreamento do espa\u00e7o do usu\u00e1rio s\u00e3o isolados dos eventos de rastreamento do n\u00facleo. O estado dos eventos pode ser visualizado atrav\u00e9s do arquivo \/sys\/kernel\/debug\/tracing\/user_events_status, enquanto a inscri\u00e7\u00e3o de eventos e a grava\u00e7\u00e3o de dados s\u00e3o feitas atrav\u00e9s do arquivo \/sys\/kernel\/debug\/tracing\/user_events_data.\n
Adicionado um mecanismo de rastreamento (probe) de chamadas de fun\u00e7\u00f5es \u2014 fprobe. A API fprobe \u00e9 baseada no ftrace, mas se limita apenas \u00e0 capacidade de anexar manipuladores de callback aos pontos de entrada e sa\u00edda das fun\u00e7\u00f5es. Ao contr\u00e1rio do kprobes e kretprobes, o novo mecanismo permite o uso de um \u00fanico manipulador para v\u00e1rias fun\u00e7\u00f5es ao mesmo tempo.\n
Foi encerrado o suporte para processadores ARM antigos (ARMv4 e ARMv5), que n\u00e3o possuem unidade de gerenciamento de mem\u00f3ria (MMU). O suporte para sistemas ARMv7-M sem MMU foi mantido.\n
Foi encerrado o suporte para a arquitetura semelhante ao RISC NDS32, utilizada nos processadores da Andes Technologies. O c\u00f3digo foi removido devido \u00e0 falta de manuten\u00e7\u00e3o e \u00e0 aus\u00eancia de demanda pelo suporte ao NDS32 no n\u00facleo do Linux (os usu\u00e1rios restantes utilizam vers\u00f5es especializadas do n\u00facleo oferecidas pelos fabricantes de hardware).\n
Por padr\u00e3o, a constru\u00e7\u00e3o do n\u00facleo com suporte ao formato de arquivos execut\u00e1veis a.out para as arquiteturas alpha e m68k, onde esse formato ainda \u00e9 utilizado, est\u00e1 desativada. Provavelmente, o suporte ao obsoleto formato a.out ser\u00e1 completamente removido do n\u00facleo em breve. Os planos para a remo\u00e7\u00e3o do formato a.out est\u00e3o sendo discutidos desde 2019.\n
Para a arquitetura PA-RISC, foi implementado suporte m\u00ednimo para o mecanismo vDSO (objetos compartilhados din\u00e2micos virtuais), que fornece um conjunto limitado de chamadas de sistema acess\u00edveis no espa\u00e7o do usu\u00e1rio sem a necessidade de altern\u00e2ncia de contexto. O suporte ao vDSO possibilitou a execu\u00e7\u00e3o com pilha n\u00e3o execut\u00e1vel.\n
Foi adicionada a suporte ao mecanismo Intel HFI (Hardware Feedback Interface), que permite que o hardware envie informa\u00e7\u00f5es sobre a performance atual e efici\u00eancia energ\u00e9tica de cada CPU para o n\u00facleo.\n
Adicionado um driver para o mecanismo Intel SDSi (Software-Defined Silicon), que permite a ativa\u00e7\u00e3o de recursos adicionais no processador (como instru\u00e7\u00f5es especializadas e mem\u00f3ria cache adicional). A ideia \u00e9 que chips com funcionalidades expandidas bloqueadas possam ser vendidos a um custo mais baixo e, posteriormente, essas funcionalidades podem ser 'compradas' e ativadas sem a necessidade de substituir fisicamente o chip.\n
Foi adicionado o driver amd_hsmp para suporte \u00e0 interface AMD HSMP (Host System Management Port), que fornece acesso a fun\u00e7\u00f5es de gerenciamento de CPU por meio de um conjunto de registradores especiais, surgindo nos processadores de servidor AMD EPYC a partir da gera\u00e7\u00e3o Fam19h. Por exemplo, atrav\u00e9s do HSMP, \u00e9 poss\u00edvel obter dados sobre consumo de energia e temperatura, definir limites de frequ\u00eancia, ativar v\u00e1rios modos de aumento de desempenho e gerenciar par\u00e2metros de opera\u00e7\u00e3o da mem\u00f3ria.\n
Na interface de entrada\/sa\u00edda ass\u00edncrona io_uring, foi implementada a op\u00e7\u00e3o IORING_SETUP_SUBMIT_ALL para registrar um conjunto de descritores de arquivo no buffer de anel, assim como a opera\u00e7\u00e3o IORING_OP_MSG_RING, que permite enviar um sinal de um buffer de anel para outro buffer de anel.\n
No mecanismo DAMOS (Data Access Monitoring-based Operation Schemes), que permite liberar mem\u00f3ria levando em conta a frequ\u00eancia de acesso \u00e0 mem\u00f3ria, foram expandidas as capacidades de controle das opera\u00e7\u00f5es de mem\u00f3ria a partir do espa\u00e7o de usu\u00e1rio.\n
A terceira s\u00e9rie de patches foi integrada com a implementa\u00e7\u00e3o do conceito de folhetos de p\u00e1ginas de mem\u00f3ria (page folios), que se assemelham \u00e0s p\u00e1ginas de mem\u00f3ria compostas (compound pages), mas diferem pela sem\u00e2ntica aprimorada e uma organiza\u00e7\u00e3o de trabalho mais clara. O uso de folhetos permite acelerar a gest\u00e3o de mem\u00f3ria em alguns subsistemas do n\u00facleo. Nos patches propostos, foi feita a transi\u00e7\u00e3o para folhetos nas fun\u00e7\u00f5es internas de gerenciamento de mem\u00f3ria, incluindo varia\u00e7\u00f5es da fun\u00e7\u00e3o get_user_pages(). Ofereceu-se suporte para a cria\u00e7\u00e3o de folhetos grandes no c\u00f3digo de leitura preditiva de dados.\n
No sistema de constru\u00e7\u00e3o, passou a haver suporte para as vari\u00e1veis de ambiente USERCFLAGS e USERLDFLAGS, por meio das quais \u00e9 poss\u00edvel passar flags adicionais para o compilador e o vinculador.\n
No subsistema eBPF, no mecanismo BTF (BPF Type Format), que fornece informa\u00e7\u00f5es para verifica\u00e7\u00e3o de tipos no pseudoc\u00f3digo BPF, foi implementada a possibilidade de adicionar anota\u00e7\u00f5es a vari\u00e1veis que fazem refer\u00eancia a \u00e1reas de mem\u00f3ria no espa\u00e7o de usu\u00e1rio. As anota\u00e7\u00f5es ajudam o sistema de verifica\u00e7\u00e3o do c\u00f3digo BPF a identificar e verificar acessos \u00e0 mem\u00f3ria de maneira mais eficaz.\n
Foi proposto um novo manipulador de aloca\u00e7\u00e3o de mem\u00f3ria para armazenar programas BPF carregados, que permite um uso mais eficiente da mem\u00f3ria em situa\u00e7\u00f5es de carregamento de um grande n\u00famero de programas BPF.\n
Na chamada do sistema madvise(), foi adicionado o sinalizador MADV_DONTNEED_LOCKED, que complementa o j\u00e1 existente MADV_DONTNEED, atrav\u00e9s do qual o n\u00facleo pode ser informado antecipadamente sobre a libera\u00e7\u00e3o de um bloco de mem\u00f3ria, ou seja, que esse bloco n\u00e3o \u00e9 mais necess\u00e1rio e pode ser utilizado pelo n\u00facleo. Ao contr\u00e1rio do MADV_DONTNEED, o uso do sinalizador MADV_DONTNEED_LOCKED \u00e9 permitido para p\u00e1ginas de mem\u00f3ria que est\u00e3o fixadas na RAM, que ao serem chamadas com madvise s\u00e3o liberadas sem mudar seu status fixo e, caso haja uma chamada subsequente ao bloco e uma gera\u00e7\u00e3o de 'page fault', retornam mantendo a fixa\u00e7\u00e3o. Adicionalmente, foi feita uma modifica\u00e7\u00e3o que permite usar o sinalizador MADV_DONTNEED com grandes p\u00e1ginas de mem\u00f3ria no HugeTLB. <\/ul>\n
Virtualiza\u00e7\u00e3o e seguran\u00e7a<\/b>\n
\n
Para a arquitetura x86, foi adicionada a compatibilidade com o mecanismo de prote\u00e7\u00e3o de execu\u00e7\u00e3o de comandos Intel IBT (Indirect Branch Tracking), que dificulta o uso de t\u00e9cnicas de explora\u00e7\u00e3o por meio de Programa\u00e7\u00e3o Orientada a Retorno (ROP, Return-Oriented Programming), onde a explora\u00e7\u00e3o \u00e9 formada como uma cadeia de chamadas de peda\u00e7os j\u00e1 existentes de instru\u00e7\u00f5es em mem\u00f3ria, terminando com uma instru\u00e7\u00e3o de retorno de controle (geralmente, estas s\u00e3o as finaliza\u00e7\u00f5es de fun\u00e7\u00f5es). A ess\u00eancia do m\u00e9todo de prote\u00e7\u00e3o implementado est\u00e1 em bloquear desvios indiretos para o corpo da fun\u00e7\u00e3o atrav\u00e9s da adi\u00e7\u00e3o, no in\u00edcio da fun\u00e7\u00e3o, de uma instru\u00e7\u00e3o especial ENDBR, permitindo a execu\u00e7\u00e3o via desvio indireto somente se o desvio apontar para esta instru\u00e7\u00e3o (um chamado indireto por meio de JMP e CALL deve sempre chegar \u00e0 instru\u00e7\u00e3o ENDBR, localizada no in\u00edcio da fun\u00e7\u00e3o).\n
Foi ativada uma verifica\u00e7\u00e3o mais rigorosa dos limites de buffers nas fun\u00e7\u00f5es memcpy(), memmove() e memset(), realizada durante a fase de compila\u00e7\u00e3o ao habilitar o modo CONFIG_FORTIFY_SOURCE. A modifica\u00e7\u00e3o adicionada consiste na verifica\u00e7\u00e3o de sa\u00eddas dos limites de elementos de estruturas, cujos tamanhos s\u00e3o conhecidos. Observa-se que essa possibilidade implementada ajudaria a bloquear todas as vulnerabilidades de estouro de buffer relacionadas ao memcpy() no n\u00facleo, identificadas pelo menos nos \u00faltimos tr\u00eas anos.\n