Code morphing onderzocht: de Crusoe reverse engineered

Bij Real World Technologies zijn een tweetal technische artikelen verschenen waarin uitgebreid de werking van de code morphing software van Transmeta en de architectuur van de TM5xxx-processorfamilie wordt ontleed. Al sinds de introductie van de processor in 1999 is er veel gespeculeerd over de interne werking van de Crusoe-processors, maar Transmeta heeft nooit veel details vrij willen geven. Zo zou een interessante vraag bijvoorbeeld kunnen zijn hoe de Crusoe-processor presteert wanneer de code morphing laag uitgeschakeld wordt en het OS direct de processor kan aansturen.

Uit de tweetal artikelen blijkt al snel dat het aansturen van de Crusoe-processor zonder gebruik te maken van de code morphing software theoretisch gezien mogelijk is, maar het niet haalbaar is om dit fatsoenlijk in bijvoorbeeld Linux te implementeren. Dit heeft verschillende redenen. Zo is het geheugenmanagement verre van x86-compatible. Een ander probleem is het feit dat de processor blijkbaar problemen heeft om omhoog te schalen in kloksnelheid. Hierdoor mogen sommige instructieparen niet aangeboden worden op alle kloksnelheden omdat deze anders meer dan één klok nodig zouden hebben alvorens resultaat te geven. Verder zijn er ook nog enkele andere problemen die het erg lastig maken om de processor direct aan te sturen. Een interessant stuk leesvoer voor de echte geeks:

In the interest of finally revealing what others have merely speculated on, the author has successfully reverse engineered a substantial part of the native Crusoe architecture and instruction set, right down to the binary instruction encodings and functional unit specifics for the TM5xxx series of processors.

It is important to note that absolutely no proprietary trade secrets were known a priori for this research, nor does the author have any relationship with the company or its employees. All information presented here is strictly the result of clean room reverse engineering over the course of the past few months.

Overzicht van de verschillende software lagen bij de Crusoe-architectuur

Reacties (15)

[Keyser]

het eerste wat ik dacht was:
Met zoveel lagen "software" wordt alles erg traag.
Misschien heeft iemand hier veel verstand van?

[Luxx]

Iedere laag die je toevoegd geeft theoretisch natuurlijk een vertraging. Je moet er alleen we rekening mee houden dat een Intel/AMD processor (Die ook x86 uitvoert) deze ook eerst naar micro-ops (oke, dit is niet het zelfde als VLIW) wordt vertaalt. Het verschil is dus kleiner dan het lijkt.

Verder worden deze processoren niet met het oog op brute kracht gebouwd, maar met het oog op energiezuinigheid. Door een extra laag kan je instructies wel zo organiseren, en eenvoudig houden, dat alles met minder hardware en minder dataverplaatsingen gedaan wordt. Hier win je dus energietechnisch veel! vandaar dat er dus toch een markt voor deze processors bestaat. En met de groeiende prestaties van deze processors(lijn), kan het best wel eens zijn dat voor behoorlijk marktsegment deze processor voldoende is. Kortom, Ik geloof wel dat er toekomst voor Transmeta is.

[-=bas=-]

Deze laagjes zitten heel dicht op een heel snelle core. En tevens zitten er allerlei truukjes in de CPU om het toch wat sneller te maken (maar details hierover staan in de artikelen en bijbehorende documenten)
Misschien kan je de laagjes beter zien als (snelle)flexibele hardware en niet als (trage) software.

Maar brute snelheid is niet waar het om gaat bij Crusoe procressoren.

[familyman]

De laagjes zijn volgens mij ook meer een conceptueel idee van hoe de werking in elkaar steekt.

Dat betekent niet noodzakelijk - eerst doet laag 1 dit, als alles klaar is en laag 1 bevestigd dat en laag 2 is er klaar voor, dan doet laag 2 dat, als alles klaar is en laag 2 bevestigd dat en laag 3 is er klaar voor, dan doet laag 3 dat, als alles klaar is en laag 3 bevestigd dat dan koppeld die dat terug aan laag 1 en begint de volgende stap.

conceptueel denken zorgt er ook voor dat problemen op ongeveer dezelfde manier worden opgelost en dat iedereen weet hoe hij een oplossingsrichting moet uitkiezen.

er zal wel een vertragingsaspect inzitten (het blijft een soort emuleren), maar niet heel dramatisch, lijkt me.

[roelio]

Traag in vergelijking met wat?
Dit is de manier waarop deze CPU werkt, dus moet je ook vergelijkingsmateriaal hebben... En dat staat in het artikel, dat is niet zo eenvoudig uit te voeren

[JeroenB]

[...]niet haalbaar is om dit fatsoenlijk in bijvoorbeeld Linux te implementeren. Dit heeft verschillende redenen. Zo is het geheugenmanagement verre van x86-compatible.

Dat zegt opzich natuurlijk vrij weinig aangezien er ook Linux beschikbaar is voor processoren die zelf ook natively allesbehalve x86-compatible zijn, ook op het gebied van geheugenmanagement, zoals IA-64. Die noem ik omdat het ook VLIW is, dus wie weet zou IA-64 Linux te porten zijn naar de Crusoe

[P_de_B]

Op zich een heel intressant artikel. Wat vreemd is, is dat op GoT zeer streng opgetreden wordt tegen reverse engineren en hier op de frontpage is er een heel artikel over te vinden.

[Verwijderd]

Lekker consequent, moeilijk doen over reverse engineeren en verder wel allemaal samba gebruiken

[Verwijderd]

Als dit mogelijk is dan moet het reverse engineeren van een GPU zoals die van ATI of NVidia al helemaal mogelijk zijn. Deze fabrikanten weigeren tegenwoordig open source drivers voor hun kaarten uit te brengen (of support te bieden aan ontwikkelaars hiervoor) omdat ze bang zijn dat kennis over de werking van hun apparaat uitlekt. Terwijl dat wel werkelijk heel interessant is. (daarom juist )

Met dit bericht blijkt maar weer dat het ondoendelijk is om zulke kennis geheim te houden, informatie terughouden als machtsmiddel werkt maar tijdelijk, op zijn best.

[Verwijderd]

Dat is altijd zo,
Als iets te intresant word word het gekraakt.
en het beveiligen van software is daaom ook iets wat altijd tijdelijk is , je kan nooit iets op die manier geheim houden.

[Verwijderd]

Alleen nog even wachten tot gegeneraliseerde decompilers als http://boomerang.sourceforge.net wat uit de kinderschoenen komen (deze is al behoorlijk ver), dan is het allemaal nog een stuk eenvoudiger.

[Verwijderd]

Wel onthouden dan dat ze hier wel maanden mee bezig zijn geweest. Niet ff 1-2-3 werk dus.

[Taennyn]

De bedoeling is ook dat het tijdelijk geheim blijft. Ze hopen dat de informatie die ze verbergen lang genoeg verborgen blijft om de concurrentie te vertragen op dat punt zodat ze hen dus weer een stapje voor zijn.

[L-project]

Zoals Taennyn al zegt gaat het er met name om de informatie zolang uit handen te houden van de concurrent dat deze een (hopelijk forse) achterstand heeft.

Daarnaast moet je bedenken dat de Code Morphing software en/of de Crusoe CPU waarschijnlijk wel voldoende gepatenteerde technieken gebruiken om een rechtstreeks kopieren onmogelijk te maken. Dan zal de concurrent wel veel nuttige, maar ook niet direct toepasbare, informatie tegenkomen. Tevens mis je het flankerende onderzoek wat ervoor is uitgevoerd, en wat natuurlijk niet te reverse-engineeren is.

Oh, en het simpelweg namaken van de Crusoe CPU is uiteraard ook verboden. Dus er is redelijk wat afgedekt.

Het probleem is dat je wel mag achterhalen hoe iets werkt (wat dacht je dat AMD en Intel doen elke keer dat de ander een nieuwe CPU heeft uitgebracht?), maar dat je daarmee nog niet zomaar iets mag en kan gaan doen.