systemd 252 arriva con il supporto UKI, miglioramenti e altro ancora

systemd è un insieme di daemon, librerie e strumenti di amministrazione del sistema progettati come piattaforma centrale di configurazione e amministrazione per l'interfaccia con il kernel di sistema. 

Dopo cinque mesi di sviluppo è stato annunciato il rilascio della nuova versione di systemd 252, versione in cui il cambiamento chiave nella nuova versione è stata l'integrazione di supporto per un processo di avvio modernizzato, che consente di verificare non solo il kernel e il bootloader, ma anche i componenti dell'ambiente di sistema sottostante utilizzando le firme digitali.

Il metodo proposto prevede l'uso di un'immagine del kernel unificata UKI (Immagine del kernel unificata) al caricamento, che combina un driver per il caricamento del kernel da UEFI (UEFI boot stub), un'immagine del kernel Linux e l'ambiente di sistema initrd caricato in memoria, utilizzato per l'inizializzazione nella fase precedente al montaggio root di FS .

Articolo correlato:

Propongono di modernizzare il processo di avvio di Linux

In particolare i vantaggi systemd-cryptsetup, systemd-cryptenroll e systemd-creds sono stati adattati per utilizzare queste informazioni, in modo da poter garantire che le partizioni del disco crittografate siano vincolate a un kernel con firma digitale (in questo caso, l'accesso alla partizione crittografata viene fornito solo se l'immagine UKI ha superato la verifica basata sulla firma digitale). nel TPM).

Inoltre, è inclusa l'utilità systemd-pcrphase, che consente di controllare l'associazione di varie fasi di avvio ai parametri posti in memoria dai crittoprocessori che supportano la specifica TPM 2.0 (ad esempio, è possibile rendere disponibile solo la chiave di decrittografia della partizione LUKS2 nell'immagine initrd e bloccarne l'accesso nei download successivi).

Principali novità di systemd 252

Altre modifiche che si distinguono in systemd 252, è che sCi siamo assicurati che la locale predefinita sia C.UTF-8 se nella configurazione non sono specificate altre impostazioni locali.

Oltre ad esso anche nel systemd 252 implementato la capacità di eseguire un'operazione preimpostata di servizio completo ("systemctl preset") durante il primo avvio. L'abilitazione dei preset all'avvio richiede una build con l'opzione "-Dfirst-boot-full-preset", ma è pianificata per essere abilitata per impostazione predefinita nelle versioni future.

Nelle unità di gestione utente utilizzare il controller delle risorse della CPU, che ha consentito di garantire che l'impostazione CPUWeight venga applicata a tutte le unità slice utilizzate per partizionare il sistema in slice (app.slice, background.slice, session.slice) per isolare le risorse tra diversi servizi utente, in competizione per le risorse della CPU. CPUWeight supporta anche un valore "inattivo" per attivare la modalità di locazione corretta.

D'altra parte, nel processo di inizializzazione (PID 1), aggiunta la possibilità di importare le credenziali dai campi SMBIOS (Tipo 11, "catene di provider OEM") oltre a definirle tramite qemu_fwcfg, che semplifica il provisioning delle credenziali per le macchine virtuali ed elimina la necessità di strumenti di terze parti come cloud-init e accensione.

Durante l'arresto, la logica per lo smontaggio dei file system virtuali (proc, sys) è stata modificata e le informazioni sui processi che bloccano lo smontaggio del file system vengono salvate nel registro.

Il bootloader SD ha aggiunto la possibilità di eseguire l'avvio in modalità mista, eseguendo un kernel Linux a 64 bit dal firmware UEFI a 32 bit. Aggiunta la possibilità sperimentale di applicare automaticamente le chiavi SecureBoot dai file che si trovano su ESP (EFI System Partition).

Aggiunte nuove opzioni all'utilità bootctl "–all-architectures" per installare i binari per tutte le architetture EFI supportate, «–root=” e “–immagine=» per lavorare con una directory o un'immagine disco, «--install-source=» per definire il font da installare, «--efi-boot-option-description=» per controllare i nomi delle voci di avvio.

Delle altre modifiche che si distinguono da systemd 252:

• systemd-nspawn consente l'uso di percorsi di file relativi nelle opzioni “–bind=” e “–overlay=”. Aggiunto supporto per l'opzione 'rootidmap' all'opzione "–bind=" per associare l'ID utente root sul contenitore al proprietario della directory montata sul lato host.
• systemd-resolved utilizza il pacchetto OpenSSL come back-end di crittografia per impostazione predefinita (il supporto di gnutls viene mantenuto come opzione). Gli algoritmi DNSSEC non supportati ora vengono trattati come non sicuri invece di restituire un errore (SERVFAIL).
• systemd-sysusers, systemd-tmpfiles e systemd-sysctl implementano la capacità di passare la configurazione attraverso il meccanismo di archiviazione delle credenziali.
• Aggiunto il comando 'confronta versioni' a systemd-analyze per confrontare le stringhe con i numeri di versione (simile a 'rpmdev-vercmp' e 'dpkg –compare-versions').
• Aggiunta la possibilità di filtrare le unità per maschera al comando 'systemd-analyze dump'.
• Quando si sceglie una modalità di sospensione a più stadi (sospensione e ibernazione, ibernazione dopo ibernazione), il tempo trascorso in modalità standby viene ora selezionato in base alla durata residua della batteria prevista.
• Una transizione istantanea alla modalità di sospensione viene effettuata quando la carica della batteria è inferiore al 5%.

Vale anche la pena ricordare che nel 2024, systemd prevede di smettere di supportare il meccanismo di limitazione delle risorse di cgroup v1, deprecato nella versione 248 di systemd. Si consiglia agli amministratori di occuparsi in anticipo dello spostamento dei servizi collegati a cgroup v1 a cgroup v2.

La differenza fondamentale tra cgroup v2 e v1 è l'uso di una comune gerarchia di cgroup per tutti i tipi di risorse, anziché gerarchie separate per l'allocazione delle risorse della CPU, la gestione della memoria e l'I/O. Gerarchie separate comportano difficoltà nell'organizzazione dell'interazione tra i driver e costi aggiuntivi per le risorse del kernel quando si applicano regole per un processo denominato in gerarchie diverse.

Nella seconda metà del 2023, si prevede di interrompere il supporto delle gerarchie di directory divise, quando /usr viene montato separatamente da root, o le directory /bin e /usr/bin, /lib e /usr/lib vengono separate.