Quando ad inizio anno c’è stato il rush di aggiornamenti per Meltdown sui vari OS, parecchi sistemi BSD sono rimasti indietro.

Tra i sistemi Unix-like come – appunto – BSD, sicuramente il fatto di avere una base utente molto più limitata rispetto ad altre controparti (leggi Linux) ha penalizzato molto l’arrivo di queste patch, sia per una disponibilità molto minore di sviluppatori che per una base utente di test molto ridotta.

Qualche giorno fa vi avevamo parlato dell’arrivo delle patch per Meltdown su FreeBSD, che seppur non sia stato il primo di quella famiglia a riceverle (il primo BSD fu DrabgoFlyBSD che le ricevette il 5 Gennaio), sicuramente è uno dei sistemi Berkeley Software Distribution più utilizzati.

Finalmente anche il fratello OpenBSD, famoso per essere tra i più sicuri della famiglia, riceve queste patch disponibili da ieri, come si evince da un commit nel kernel da parte dello sviluppatore Philip Guenther:

When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread’s real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace.

Quando una syscall, una trap o un interrupt porta la CPU da userspace al kernel, il codice trampolino scambia le tabelle delle pagine, girando lo stack sul reale thread nel kernel, dopodichè copia i bit necessari dallo stack trampolino. Nel ritorno allo userspace, avviene l’inverso: viene ricreato il frame iretq sullo stack trampolino, vengono girati gli stack, scambiate le tabelle delle pagine e si ritorna allo userspace.

Tecnicismi a parte, in soldoni viene utilizzato uno stack intermedio (chiamato trampolino) per il passaggio dei dati, assicurandosi che questo avvenga solo al cambio di contesto, e mitigando quindi l’applicazione delle vulnerabilità che sfruttano Meltdown.

Su diversi forum e sistemi di commenti impazza la discussione che vede due parti contrapporsi: la prima, valutando il fatto che gli sviluppatori BSD siano venuti a conoscenza di questi bug solo da inizio Gennaio (mentre pare che le discussioni su eventuali mitigation nel kernel Linux siano partite diverse settimane prima) denoti la rapidità del fixing da parte di quegli OS, mentre la seconda sostiene che il fatto di avere patch ad inizio Gennaio per tutti gli OS e vedere i BSD arrivarci solo a fine Febbraio indichi sostanzialmente che la forza lavoro su quegli OS sia decisamente ridotta e poco reattiva.

L’importante è avere le patch, alla fine dei conti, ma ci domandiamo: questo ritardo può pilotare la scelta di uno o l’altro OS per ambienti in cui effettivamente avrebbero senso entrambi?

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.