Iso Loader: sulle tracce di un grosso bug

Non possono essere così niubbi da lasciare pezzi di kernel in memoria quando si esce da linux.

dai caxxo daiiiiiii
che ce sto loader !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

sorry ho confuso cmq sono 2 grandi! e mi sorprende ancora come non si avventurano nell' hack della ps3...

se si rivela un bug sfruttabile per l'esecuzione dell'isoloader, la sony potrebbe tagliare la testa al toro eliminando il supporto per linux

Ci doveva pensare prima (sony) di mettere in vendita la prima ps3.
Una volta che sei entrato da una porta, poi entri in un'altra e non si sa più dove potresti andare a ficcare il naso.

perchè dopo il crash e rispettivo riavvio è impossibile che l'immagine di una iso resti nontata su un driver virtuale... mi sembra ovvio.

Da quello che ho potuto capire l'XMB è in esecuzione dietro le quinte anche se la ps3 parte in otherOS

Leggendo con un pò di attenzione quello che Hackobell dovrebbe aver fatto è (per grandi linee):

• Ricompilato un kernel di linux con supporto per un BR-ROM virtuale;
• Montato un'immagine nel drive virtuale (a questo punto il sistema leggerebbe il tipo di immagine e invierebbe delle informazioni al processore ps2 oppure al cell, tutto questo con l'XMB sempre attiva in background);
• Causato un crash in Linux durante il reboot in gameOS;
• l'XMB in background a questo punto si rivelerebbe e intercetterebbe l'immagine...

Chiaramente l'hack è tutta da verificare e, se reale, ancora con molte limitazioni.
Ma non credo sia un fake: molti dei dettagli pubblicati (che qui non ho riportato) mi sembrano plausibili, ed è comunque molto di più di quello che team Paradox ha lasciato trapelare nei suoi .nfo

Certamente mi pareva strano che lo mettesse per fare felici gli utenti linuxari...

Purtroppo vero...ma alla fine ne stiamo giovando tutti

A me non risulta, alcuni processi sono attivi quando viene caricato il loader che permette l' esecuzione di Linux, ma nel momento in cui fai il boot dell' SO vengono terminati, quindi la vedo dura (anche perchè non sarebbe solo un baco assurdo, ma uno spreco inutile di RAM, e già per far girare un SO adesso è poca...)...

Si può fare tranquillamente e fino a qui la cosa è normale.

Il problema è che l' XMB non gira in background, almeno da quello che so, infatti se devi passare da Linux al GameOS devi fare un Hard Reset oppure lo fa automaticamente la Ps3 quando gli dai il comando, in ogni caso il reboot è necessario, proprio per terminare tutti i processi prima di riaprire l' XMB.

Possibile che ci sia riuscito, far crashare un SO non è difficile, sopratutto quelli che girano adesso su PS3...

Questo è il passaggio meno chiaro, sopratutto perchè le partizioni in ext (linux per capirci) non vengono lette dalla Ps3 (GameOS) che manco le riconosce, come si fa a fare il mount di un file in una partizione che non viene riconosciuta? E' come avere un PC con dentro Windows e Linux, non è possibile montare un ISO in un drive virtuale di linux e farla leggere da Windows, manco te la mostra la partizione in Ext, e se te la fa vedere non riesce a leggere i dati all' interno... Mi piacerebbe avere un chiarimento proprio su questo punto, il resto può essere tranquillamente vero per quanto ne sappiamo.

fin qui diciamo che ci può anche stare, anche so ho dubbi. edit:come ha detto qualcunaltro bisogna fare un hard reset, se così fosse è addirittura impossibile

ecco e quì che spara la cavolata( fino a prova contraria),durante il reboot i vari processi di linux vengono killati e linux si prepara ad uno "spegnimento".

cmq l'immagine è montata su linux , su hd, ha bisogno delle system call del kernel di linux per accedere al driver virtuale,e anche se restano caricate in memoria,perchè mai l'XMB dovrebbe eseguire delle system call di linux ? tra l'altro le system call di linux sono incompatibili con l'XMB ammeno che l'XMB non sia un derivato di linux.
per me resta una cavolata imho.

Il motivo potrebbe essere (pura speculazione): negare l'accesso alla GPU per otherOS.

Infatti Hackobell per il momento sostiene di essere riuscito a far girare soltanto le iso di giochi PSX (ps1) montate via drive BD-ROM virtuale da un disco esterno in fat32 (quindi con il limite file a 4 GB).

Non voglio mettere la mano sul fuoco, ma l'assunto di una sorta di XMB semi-dev in esecuzione in background che lui pone, nel caso si dimostrasse vero, mostra un via percorribile per un hack.

Non c'è reboot (sempre seguendo le sue indicazioni): il crash avviene durante la procedura di riavvio (non è specificato a che punto).

Ripeto non sono qui per difendere Hackobell, sto solo cercando di non liquidare con sufficienza solo perché non si è ritenuto opportuno approfondire e capire, oppure perché si parte da presupposti che possono essere errati...

Infatti ci avevo pensato anch' io, ma comunque per negare l' accesso alla GPU per l' SO alternativo non credo sia necessario mantenere attivi i processi dell' XMB, è molto più semplice un processo alternativo che blocca la GPU quando si fa il boot dell' OS secondario, tra l' altro è molto più semplice, sicuro e ciuccia meno RAM!

Ma lo stesso non capisco come sia possibile, il disco per giochi superiori a 4 Gb dovrà essere partizionato in ext o in NTFS, il problema è che l' ext non viene letto dal GameOS, mentre l' NTFS (non so se viene letto, ma poniamo di si) non è che sia il massimo su Linux, i driver migliori sono solo per il Read (nessuna possibilità di scrittura quindi) perchè i driver ntfs-3g sono ancora Beta e hanno problemi, ma comunque utilizzando una NTFS passando per Linux ci saranno sempre problemi, il più comune è tra l' altro il più grosso per noi, ovvero il transfer-rate, che a volte cala vistosamente, ma se succede mentre si gioca il risultato è un bel freeze del gioco...

Se fosse vero si, e probabilmente sarebbe anche la via più semplice, se si riuscisse a risolvere il problema del partizionamento dell' HD.

Si ma durante la procedura di riavvio i processi vengono tutti killati, a differenza di Windows linux mostra i processi che vengono terminati, e mentre in avvio si può decidere quali processi avviare e quali no durante lo spegnimento (e conseguente riavvio) non si può scegliere cosa terminare e cosa no, inoltre un crash generalmente comporta il termine di tutti i processi, non capisco come sia riuscito lui a mantenerne alcuni attivi.

D' accordissimo con te, infatti non ho detto che sia un fake sicuro, solo che i metodi da lui descritti sono molto poco ortodossi , e alcuni dei quali francamente mi sembrano impossibili dato che comunque da un bel pò sono passato all' open source, quindi almeno un pò me ne intendo, detto questo la Ps3 non è un PC, e le varie applicazioni che può avere Linux non le ho ancora studiate a fondo (diciamo pure che devo ancora iniziare a smanettarci ), quindi potrebbe anche essere vero, solo che un baco del genere mi sembra davvero troppo assurdo, sappiamo tutti che la consolle più moddabile generalmente è quella che vende di più, ma qui è come se la Sony gli avesse aperto la porta principale!

EDIT:

budino ha riassunto il problema più grosso in poche parole, a questo punto direi che l' unica cosa da fare è attendere delucidazioni da Hackobell in merito.

Intanto $ony ha aggiornato le specifiche dell'Open Platform:

Il sito è stato aggiornato il: Apr 4 13:17 index.html
Allora, tutti ancora sicuri che non c'era niente di utile in otheros.self?

ps: gatsu84> questa discussione la continuo martedì, intanto buona pasquetta

coincidenza ?

a parte gli scherzi mi viene da pensare che il modo migliore per impedire l'accesso a linux ad alcune risorse ( RSX, flash contenente il firmware) è tramite virtualizzazione così l'XMB ( o chi per lui ) "decide" a quale risorse hardware bloccare l'accesso.
ma anche se linux gira su una macchina virtuale mi viene difficile credere che sia possibile fare quello che dice hackobell...

Non so se si tratti di coincidenza o meno però Hackobell parlava di un baco nei firmware (1.60 incluso) e non nel file self che serve per far partire l' SO alternativo.

PS: potrebbero averlo aggiornato per cercare di costringere anche i più smanettoni ad aggiornare il FW, anche se servirà comunque a poco perchè quel file è reperibile dappertutto, non solo nel sito ufficiale!

speriamo che trovino un bel bug!!!!!!!!!!!!!!!!!