Re: Segfaults
On 13/10/21 07:27, Diego Zuccato wrote: Il 12/10/2021 19:43, Davide Prina ha scritto: vedendo qui: https://sources.debian.org/src/openblas/0.3.13+ds-3/driver/others/memory.c/ l'istruzione è questa: map_address = (*func)((void *)base_address); Uhm... Il codice usa l'array memoryalloc come lista di puntatori a funzione. Però poi itera gli elementi senza verificare se uno di essi è NULL. E l'ultimo lo è sempre (riga 2664). se devo essere onesto mi sono un po' perso, anche perché non sapendo come sono impostate quelle variabili non si può sapere cosa memoryalloc contenga come elemento 0 e successivi se non erro li viene eseguita la funzione che è stata inserita in memoryalloc nella posizione 0 passando come parametro base_address con cast void* e memoryalloc è un vettore di puntatori a funzione che prendono come parametro void*... però tale lista dipende, penso, dal tuo sistema e da come sono configurate determinate variabili visto che l'errore è jump to invalid address at 0x0 sembra che il puntatore a funzione memoryalloc[i] punti all'indirizzo 0x0 che non dovrebbe prima di tutto essere raggiungibile da un programma e quindi non dovrebbe contenere una funzione da eseguire. Probabilmente la condizione per il while alla 2791 dovrebbe essere relativa a *func, non a func... quindi tu dici il memoryalloc[i] == NULL func -> memoryalloc[i] != NULL, poiché il suo indirizzo è quello relativo all'i-esimo elemento di memoryalloc, ma tale i-esimo elemento contiene NULL e quindi quando esegue la funzione cerca di andare all'indirizzo 0x0 per eseguirla è vero l'istruzione dovrebbe essere while ((*func != NULL) && (map_address == (void *) -1)) poiché func è sempre un elemento di memoryalloc. Però questo vuol dire che non ha trovato nessun metodo per eseguire l'allocazione di memoria... quindi potrebbe avere problemi dopo, anche perché c'è un ciclo più esterno e quindi rieseguirebbe quello più interno... potrebbe essere addirittura che memoryalloc[0] == NULL perché nessuno degli altri è stato impostato. Certo che comunque qualcosa non mi torna: se metto la -serial invece della -pthread, senza cambiare altro, octave funziona... quindi risolvi installando libopenblas0-serial e togliendo libopenblas0-pthread? interessante: $ apt show libopenblas0-serial [...] Configurazione: USE_THREAD=0 USE_OPENMP=0 INTERFACE64=0 [...] quindi magari bastava eseguire: $ USE_THREAD=0 octave o anche aggiungendo gli altri per avere octave funzionante senza segfault Altro modo è provare a prendere da testing la versione nuova e vedere se questo risolve, vedendo le dipendenze dovrebbe essere possibile installare solo il pacchetto preso da testing Purtroppo non risolve :( visto che prima funzionava puoi cercare la versione della libreria che non causava questi problemi e capire così cosa è cambiato confrontando il sorgente che ti ha indicato valgrind le versioni precedenti della libreria li trovi qui: https://snapshot.debian.org/binary/libopenblas0-pthread/ o guardare nei sorgenti precedenti. Però anche in Buster c'era lo stesso while https://sources.debian.org/src/openblas/0.3.5+ds-3/driver/others/memory.c/ ma anche in Stretch https://sources.debian.org/src/openblas/0.2.19-3/driver/others/memory.c/ quindi probabilmente non la usavi o è cambiato qualcos'altro che ha fatto venire a galla questo bug Magari mi limito a segnalare la cosa al maintainer. Purtroppo è un sistema di produzione e non posso fare troppi test :( ma non puoi clonarlo in una macchina virtuale e fare da li le prove? Ciao Davide -- Esci dall'illegalità: utilizza LibreOffice/OpenOffice: http://linguistico.sf.net/wiki/doku.php?id=usaooo Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Nuovo malware per GNU/Linux (sembra una bufala!)
On 13/10/21 07:49, Marco Ciampa wrote: On Tue, Oct 12, 2021 at 07:48:07PM +0200, Davide Prina wrote: On 11/10/21 21:48, Marco Ciampa wrote: Di rootkit ce ne sono a bizzeffe. ma sono tutti neutralizzati da un sistema aggiornato e da un adeguato uso del sistema. No i rootkit sono rootkit, non puoi neutralizzarli, stai facendo confusione con i virus. per potersi installare nella tua macchina un rootkit ha bisogno che tu abbia un software con bug, che permetta all'attaccante reale/virtuale di scalare fino a root, o che tu compia azioni non adeguate (es: installare come root software preso in giro, eseguire come root software preso in giro, ...) Quindi se tu hai il sistema costantemente aggiornato e fai un uso adeguato del sistema, allora li hai neutralizzati, nel senso che non possono infettare il tuo sistema... o per la meno la maggior parte di essi non può, poi può esserci sempre un bug non conosciuto usato dall'attaccante per entrare nel tuo PC e per scalare a root. Probabilmente è per questi motivi che in GNU/Linux il malware in generale ha poca diffusione e dove l'ha è perché i sistemi non sono aggiornati o il comportamento degli utenti non è adeguato. Ciao Davide -- Elenco di software libero: http://tinyurl.com/eddgj GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Nuovo malware per GNU/Linux (sembra una bufala!)
Il 13/10/21 07:49, Marco Ciampa ha scritto: > No i rootkit sono rootkit, non puoi neutralizzarli, stai facendo > confusione con i virus. Puoi pensare ad un rootkit come ad una specie di > driver che una volta installato "abilita" certe funzionalità. Non mi pare > che si possa "neutralizzare" un rootkit come non si può "neutralizzare" > un driver, in special modo se viene compilato per una specifica versione > o insieme di versioni del kernel. Ni, li puoi individuare e rimuovere, non automaticamente questo si ma i tool per indagine in tal senso ci sono, poi a seconda della situazione agisci. -- Mario Vittorio Guenzi E-mail jcl...@tiscali.it Si vis pacem, para bellum OpenPGP_signature Description: OpenPGP digital signature
