systemd 252 chega com suporte UKI, melhorias e muito mais

systemd é um conjunto de daemons, bibliotecas e ferramentas de administração do sistema projetados como uma plataforma central de configuração e administração para interface com o kernel do sistema. 

Após cinco meses de desenvolvimento o lançamento da nova versão do systemd 252 foi anunciado, versão em que a principal mudança na nova versão foi a integração de suporte para um processo de inicialização modernizado, que permite verificar não apenas o kernel e o bootloader, mas também os componentes do ambiente do sistema subjacente usando assinaturas digitais.

O método proposto envolve o uso de uma imagem unificada do kernel UKI (Imagem de kernel unificada) em carga, que combina um driver para carregar o kernel do UEFI (stub de inicialização UEFI), uma imagem do kernel Linux e o ambiente do sistema initrd carregado na memória, usado para inicialização inicial no estágio anterior para a montagem raiz do FS .

Artigo relacionado:

Eles propõem modernizar o processo de inicialização do Linux

Em particular, os benefícios systemd-cryptsetup, systemd-cryptenroll e systemd-creds foram adaptados para usar essas informações, para que você possa garantir que as partições de disco criptografadas estejam vinculadas a um kernel assinado digitalmente (neste caso, o acesso à partição criptografada é fornecido apenas se a imagem UKI tiver passado na verificação baseada em assinatura digital). no TPM).

Além disso, o utilitário systemd-pcrphase está incluído, o que permite controlar a ligação de vários estágios de inicialização a parâmetros colocados na memória por criptoprocessadores que suportam a especificação TPM 2.0 (por exemplo, você pode tornar a chave de descriptografia de partição LUKS2 disponível apenas na imagem initrd e bloquear o acesso a ela em downloads subsequentes).

Principais novos recursos do systemd 252

Outras mudanças que se destacam no systemd 252, é que se certifique-se de que a localidade padrão é C.UTF-8 se nenhuma outra localidade for especificada na configuração.

Além disso no systemd 252 também implementou a capacidade de executar uma operação predefinida de serviço completo ("systemctl preset") durante a primeira inicialização. A ativação de predefinições no momento da inicialização requer uma compilação com a opção "-Dfirst-boot-full-preset", mas está planejado para ser ativado por padrão em versões futuras.

Nas unidades de gerenciamento de usuários, use o controlador de recursos da CPU, o que possibilitou garantir que a configuração CPUWeight seja aplicada a todas as unidades de slice usadas para particionar o sistema em slices (app.slice, background.slice, session.slice) para isolar recursos entre diferentes serviços de usuário, competindo por recursos de CPU. CPUWeight também oferece suporte a um valor "idle" para acionar o modo de concessão adequado.

Por outro lado, no processo de inicialização (PID 1), adicionado a capacidade de importar credenciais de campos SMBIOS (Tipo 11, "cadeias de provedores OEM"), bem como defini-las via qemu_fwcfg, que simplifica o provisionamento de credenciais para máquinas virtuais e elimina a necessidade de ferramentas de terceiros, como cloud-init e ignição.

Durante o desligamento, a lógica para desmontar sistemas de arquivos virtuais (proc, sys) foi alterada e as informações sobre processos que bloqueiam a desmontagem do sistema de arquivos são salvas no log.

O bootloader sd adicionou a capacidade de inicializar no modo misto, executando um kernel Linux de 64 bits a partir do firmware UEFI de 32 bits. Adicionada capacidade experimental de aplicar automaticamente chaves SecureBoot de arquivos localizados no ESP (EFI System Partition).

Adicionadas novas opções ao utilitário bootctl “–all-architectures” para instalar binários para todas as arquiteturas EFI suportadas, «–raiz=” e “–imagem=» para trabalhar com um diretório ou imagem de disco, «--install-source=» para definir a fonte a ser instalada, «--efi-boot-option-description=» para controlar os nomes das entradas de inicialização.

Das outras mudanças que se destacam do systemd 252:

• systemd-nspawn permite o uso de caminhos de arquivos relativos nas opções “–bind=" e “–overlay=". Adicionado suporte para a opção 'rootidmap' à opção "–bind=" para vincular o ID do usuário root no contêiner ao proprietário do diretório montado no lado do host.
• systemd-resolved usa o pacote OpenSSL como backend de criptografia por padrão (o suporte gnutls é mantido como uma opção). Algoritmos DNSSEC não suportados agora são tratados como inseguros em vez de retornar um erro (SERVFAIL).
• systemd-sysusers, systemd-tmpfiles e systemd-sysctl implementam a capacidade de passar a configuração pelo mecanismo de armazenamento de credenciais.
• Adicionado o comando 'compare versões' ao systemd-analyze para comparar strings com números de versão (semelhante a 'rpmdev-vercmp' e 'dpkg –compare-versions').
• Adicionada a capacidade de filtrar unidades por máscara ao comando 'systemd-analyze dump'.
• Ao escolher um modo de suspensão de vários estágios (suspensão e hibernação, hibernação após hibernação), o tempo gasto no modo de espera agora é selecionado com base na previsão de duração restante da bateria.
• Uma transição instantânea para o modo de suspensão é feita quando há menos de 5% de carga da bateria.

Também vale a pena mencionar que em 2024, o systemd planeja parar de oferecer suporte ao mecanismo de limitação de recursos cgroup v1, obsoleto na versão 248 do systemd. Os administradores são aconselhados a cuidar da movimentação dos serviços vinculados ao cgroup v1 para o cgroup v2 com antecedência.

A diferença chave entre cgroups v2 e v1 é o uso de uma hierarquia de cgroups comum para todos os tipos de recursos, em vez de hierarquias separadas para alocação de recursos de CPU, gerenciamento de memória e E/S. Hierarquias separadas levam a dificuldades na organização da interação entre drivers e custos adicionais de recursos do kernel ao aplicar regras para um processo nomeado em diferentes hierarquias.

No segundo semestre de 2023, está planejado parar de oferecer suporte a hierarquias de diretório divididas, quando /usr for montado separadamente da raiz ou os diretórios /bin e /usr/bin, /lib e /usr/lib forem separados.