4 risposte a “La nuova vita di Bzip2”

1. 

   JustATiredMan

   8 Giugno 2019

   Rust ? e quale vantaggi ne trarrebbe ?

2. 

   Marco Bonfiglio

   11 Giugno 2019

   Rust è un linguaggio compilato recente, sviluppato all’interno di Mozilla – ma ora open source esso stesso – semplicemente per essere meglio di altri linguaggi, C per primo, sia come velocità di esecuzione che come facilità di uso – specialmente per ridurre al minimo errori introdotti dal programmatore.
   A parità di algoritmo (sequenza di istruzioni usate), per esempio ha vantaggi prestazionali rispetto a C nelle operazioni di lettura e scrittura nella memoria; quindi il primo vantaggio più immediato dovrebbe essere una maggiore velocità di esecuzione, visto che un compressore di dati usa pesantemente la memoria.
   Rust è memory safe, ovvero effettua dei controlli in fase di compilazione per evitare degli errori fatti dai programmatori nell’uso della memoria – specialmente in C, giusto per ribadire; questi errori (come buffer overflow o memory leak) lasciano zone della memoria non usate, o accedono a zone in realtà assegnate ad altri programmi, eventi che nella migliore delle ipotesi portano al blocco del programma, ma che talvolta sono usati dai malware per infiltrare i propri dati.
   Altro vantaggio di Rust, ma solo in prospettiva futura, è l’essere thread safe, ovvero avere meccanismi interni per rendere più facile – e coerente – la parallelizzazione dell’esecuzione – con ovvi vantaggi prestazionali. La caratteristica di Bzip2, per ottenere la sua efficacia di compressione, è di analizzare i dati in ingresso e ordinarli prima di comprimerli per avere dati simili vicini, cosa che aumenta l’efficacia di qualsiasi algoritmo di compressione; poterlo fare su più CPU dovrebbe essere un bel vantaggio.

3. 

   JustATiredMan

   11 Giugno 2019

   Passi il discorso delle performances, del garbage collector etc., che ovviamente, non conoscendo io rust, lo devo prendere per buono, non vedo come sia possibile avere in C o qualsiasi altro liguaggio, accesso a zone di memoria riservate ad altri programmi, quando le architetture hardware attuali, hanno tutte protezioni della memoria (discorso diverso ovviamente se in C fai firmware per microcontroller).
   Quella era roba, mi pare, che succedeva agli anni che fu con processori senza mmu.

4. 

   Marco Bonfiglio

   11 Giugno 2019

   In C è perfettamente legale creare un array da 2 elementi e cercare di accedere al ventesimo, quindi i comandi – le istruzioni per la CPU – per fare questo sono generati (in fase di compilazione) ed eseguiti: l’MMU interviene solo se la memoria a cui si accede è assegnata ad un altro programma, terminando il programma “invasore” con un errore tipo “Out of bound” o “Segmentation fault”; per questo ho detto che nella migliore delle ipotesi porta al blocco del programma. Ma se si rimane in zone sempre assegnate a quel processo (o non ancora assegnate a nessuno, per quel che ne so), l’MMU non interviene.
   Il meccanismo, se non limitato apposta, lascia spazio a degli attacchi: se il programma si aspetta una risposta da 2 KB ma 64 KB, i 62 KB in più verranno scritti (statisticamente la memoria usata sarà contigua a quella già assegnata, e apparterrà al processo stesso, quindi niente MMU). Questi dati possono essere un programma malevolo, e sarà in una posizione conosciuta, quindi accessibile con un’altra chiamata – serve un attacco diverso, per esecuzione di codice, ma esistono anche questi. L’esempio non è a caso: https://www.miamammausalinux.org/2016/02/cve-2015-7547-il-nuovo-bug-in-glibc-e-ancora-per-dns/