Hoofdcategorieën

Onderzoekers ontwikkelen crash-beveiliger voor processors

Door Hans Koevoet, woensdag 1 oktober 2008 18:16, views: 13.884

Amerikaanse onderzoekers hebben een technologie ontwikkeld die cpu's tegen foutieve commando's zou beschermen. Door de commando's eerst te laten beoordelen door een 'voorproever', zou de kans op vastlopers veel kleiner worden.

Intel Core 2Onderzoekers van de Universiteit van Michigan hebben een technologie bedacht om processors te beschermen tegen commando's die de cpu normaliter zouden doen vastlopen. Het gaat om een vinding die continu controleert in hoeverre de cpu commando's krijgt die de ontwerpers niet hadden voorzien bij het ontwerpen en testen van de cpu. Chip-ontwikkelaars als AMD en Intel onderwerpen hun processors weliswaar aan zware testprogramma's, maar wanneer de cpu's in de alledaagse praktijk worden gebruikt, krijgen ze toch vaak commando's voorgeschoteld waar de ontwerpers niet op hadden gerekend, met instabiliteit als gevolg.

De voorziening die de Amerikaanse onderzoekers nu hebben gebouwd, werkt als een soort 'instructie-voorproever'. Wanneer een niet-getest commando wordt gesignaleerd, wordt de cpu in een veilige modus geschakeld. Dit vertraagt de computer weliswaar, maar zorgt er ook voor dat de kans dat het verkeerde commando tot een crash leidt, veel kleiner wordt. "Het is alsof je op een snelle motorfiets rijdt en dan een ruig stukje in de weg ziet komen. Je voertuig verandert dan even in een trage maar veilige fiets, tot je de kuilen voorbij bent", aldus Michigan-onderzoeker Valeria Bertacco. De onderzoekers willen de voorproever nu op een fpga implementeren, waarmee een cpu beveiligd kan worden. Ze hopen dat de vinding uiteindelijk op grote schaal door processorfabrikanten in cpu's zal worden geïntegreerd.

Wanneer de instructietester ook in de praktijk blijkt te werken, zou dat processorontwikkelaars veel hoofdpijn kunnen besparen. Het is normaal dat cpu-fabrikanten nog honderden bugs vinden in processors die al lang en breed op de markt zijn. Meestal kunnen dergelijke bugs opgevangen worden met bios-updates, maar dat kan niet altijd, en dat kan grote gevolgen hebben. Afgelopen jaar bijvoorbeeld zag AMD zich gedwongen de levering van zijn quadcore-Opteron met bijna een half jaar uit te stellen, nadat er een ernstige fout in de Barcelona-kern aan het licht was gekomen.

Er bestaat echter scepsis over de effectiviteit van de vinding. Insight 64-analist Nathan Brookwood zegt er niet van overtuigd te zijn dat de commando-voorproever het Barcelona-debacle van AMD had kunnen voorkomen. Op de eerste plaats is bijna niet te overzien welke commando's wel en welke niet toelaatbaar zijn. Een tweede probleem is volgens hem dat het moeilijk is om het inschakelen van de veilige modus van een processor goed te implementeren.

Volgende 18:55
Vorige 17:36

Reacties

«  1  2  3  »

Voor servers of toepassingen waar fouten een hoop kunnen verpesten is dit wel handig. Maar voor mijn desktopje hoeft het eigenlijk niet zo van mij. Licht er eigenlijk ook aan hoevaak hij in 'veilige' modus gaat.

Inderdaad handig, plus een server staat toch 99% van de tijd duimen te draaien, tijd genoeg om kevers te vangen.

Komt er gelijk een idee bij me op: Een zelf lerend systeem die bij een crash leert welke combinatie fataal was en dit in een stukje flash geheugen geintegreerd in de cpu opslaat en de veilige modus inschakeld bij de volgende keer deze fout wordt ontdekt. Deze gegevens worden via internet samen gebracht en verspreid zodat binnen no time een stabiele cpu firmware onstaat :)

Maar ik ben bang dat dit alleen maar voor nog luiere programmeurs gaat zorgen die op een gegeven moment deze serieuze fouten niet meer uit hun progsels halen.

En zelfherstellende mainstream cpu's is toch de natte droom van menig programmeur bij de ruimtevaart nietwaar?

Ik denk dat de performance hierdoor achteruit gaat. Aan de andere kant.. processoren worden steeds sneller.. misschien dat het geen kwaad kan om een beetje snelheid in te leveren voor meer stabilitieit.

Waarom zou dat veel trager gaan? Je eerste commando moet door 2 processen heen voor er wat gebeurt. Maar daarna wordt het eerste commando dus uitgevoerd en het tweede alvast getest. Je 'verliest' alleen de tijd van het eerst opstarten. Die paar micro seconden overleef ik wel

Het lijtk op een trein. Als hij 100 rijdt maakt het niet uit of er 10 of 20 wagons zijn. ze rijden allemaal 100.

Alleen bij problemen gaat het iets langzamer. Tja...dat is beter dan helemaal STOP

[Reactie gewijzigd door Ortep]


Je hebt meer capaciteit nodig = grotere CPU of extra CPU die berekingen doet

Het lijkt idd op een trein, als hij 100 rijdt maakt het uit of er 10 of 20 wagons zijn, ze rijden welliswaar allemaal honderd maar om 10 wagons te trekken is veel minder energie nodig dan om 20 wagons te trekken. Bovendien, de maximale snelheid van een trein daalt wel naarmate hij meer gewicht moet trekken. Bij een trein zal je niet vaak maximale kracht gebruiken, maar juist bij een processor wil je dat wel. Of denk jij dat als jij in staat bent een auto te duwen dat je dan ook gelijk 50 auto's kan duwen?

[Reactie gewijzigd door Tsurany]


De trein komt trager op gang, maar als hij eenmaal 100 rijdt, blijft hij het gewoon doen. de rolweerstand is niet zo hoog, de massa wel aar dat maakt niet uit (Kijk maar eens bij de eerste wet van Newton)

Maar aangezien instructies niets 'wegen' telt dat hier niet. Het ging er om of het trager
was of niet. En de laatste wagon van een trein gaat even snel als de eerste.

En ja, ik ben in staat meerdere spoorwegwagons te duwen. Dat heb ik wel gedaan toen ik in de haven werkte.
De eerste krijg je heel traag op gang. Je schouders er tegen en gewoon gaan duwen. Na enige tijd komt hij in beweging en kan je steeds sneller. Starten is lastig maar ze rollen verbazend makkelijk. Als de volgende wagon een meter of 10 verder staat heb je al voldoende snelheid om hem er tegen aan te laten klappen. Ze gaan dan samen met de halve snelheid verder. (Wet van behoud van impuls) Maar ze bewegen wel. En juist het starten was het lastigste. je krijgt de snelheid er wel weer in. Je kan daarna deze twee weer tegen de 3e laten klappen. Dan gaan ze met zijn drieen met 2/3e van de snelheid verder. enz.


Het gaat dus niet als ze met zijn 3en tegen elkaar staan. Er moet ruimte tussen ziten.

Het grote probleem is: Hoe stop je ze :)

[Reactie gewijzigd door Ortep]


Dit is echt de slechtste voertuig vs. computer-vergelijking die ik ooit ben tegengekomen op Tweakers.

Het lijkt idd op een trein, als hij 100 rijdt maakt het uit of er 10 of 20 wagons zijn, ze rijden welliswaar allemaal honderd maar om 10 wagons te trekken is veel minder energie nodig dan om 20 wagons te trekken. Bovendien, de maximale snelheid van een trein daalt wel naarmate hij meer gewicht moet trekken. Bij een trein zal je niet vaak maximale kracht gebruiken, maar juist bij een processor wil je dat wel. Of denk jij dat als jij in staat bent een auto te duwen dat je dan ook gelijk 50 auto's kan duwen?
Damn wat een onzin. Vergelijk nooit (!!) elektronica of PC's met een mechanisch iets zoals een trein of een auto. Dat loopt zeker verkeerd af. Een auto kan je ook niet van nul tot max snelheid in 1µs, bij een PC'tje geen enkel probleem. Klok er op of klok eraf en dat ding is vertrokken... Ok sommige dingen vragen enkele kloktikken om op gang te komen, maar je begrijpt het wel.

Waarom zou dat veel trager gaan? Je eerste commando moet door 2 processen heen voor er wat gebeurt.
FPGA =! processor :o

De FPGA wordt hier alleen voor ontwikkelen/testen gebruikt.

Punt is dat je vaak niet weet wat je volgende commando is omdat dat afhankelijk is van je vorige commando. Je kan dit vaak wel een beetje voorspellen, dit doen processors al om de goede commandos alvast te laden(branchprediction), maar niet altijd dus dit zal zeker vertragend werken.
Om in de (door mij compleet uit logisch verband gerukte) trein analogie te blijven. Het is alsof die trein op een lijn met duizenden wissels rijdt en steeds alvast een wissel in rijdt zonder dat ie weet of die er daar af moest omdat de navigator een wagon er achter zit en dus pas als die wagon er is weet welke kant ie op moet... laat maar dit wordt niks |:(.
Punt is een moderne processor moet heel vaak beslissen of ie de ene of de andere code gaat uitvoeren dus je weet niet altijd welke code je in de wachtrij moet zetten. Omdat dat afhankelijk is van code die nog niet is uitgevoerd

[Reactie gewijzigd door jmzeeman]


Waarom zou dat veel trager gaan? Je eerste commando moet door 2 processen heen voor er wat gebeurt. Maar daarna wordt het eerste commando dus uitgevoerd en het tweede alvast getest. Je 'verliest' alleen de tijd van het eerst opstarten.
Dat klopt niet helemaal. Het commando wordt door de voorproever uitgevoerd en daarna wordt het resultaat beoordeeld. Als het commando wordt vrijgegeven gaat de processor het uitvoeren. Tegelijkertijd gaat de voorproever het tweede commando uitvoeren. Tegen de tijd dat dat gebeurd is, is de processor ook klaar met het eerste commando - maar dan moet de voorproever het tweede commando nog beoordelen. In die tijd staat de processor dus niets te doen.

Op zich is het een goed idee, maar dan alleen voor systemen waar betrouwbaarheid zwaarder telt dan snelheid. In de luchtvaart en ruimtevaart wordt dit soort technieken al langer toegepast. Een systeem bestaat bv. uit vier processoren, drie zijn actief en de vierde is standby. Processor 1 voert een instructie uit, processor 2 en 3 doen hetzelfde maar hun resultaten dienen alleen als vergelijkingsmateriaal en als de uitkomst van één van de processoren afwijkt wordt dat resultaat verworpen. In het meest extreme geval kan die processor worden uitgeschakeld en neemt nummer vier het over. Eigenlijk hetzelfde principe dus, alleen zijn dan meerdere processoren elkaars voorproever. Zoiets kun je dus ook doen met quadcore systemen.

Je vergeet iets heel belangrijks. Een programma wordt niet liniear afgewerkt in het geheugen je hebt ook jumps en je plaatst zaken op de stack. Je hebt meerdere programma's draaien te gelijkertijd.

Hier door weet je crash beveiliger op de voorhand niet wat hij moet testen. Hierdoor zal het hele zaakje vertraagd worden.

Ik zie dit product helemaal niet zitten. Het is zelden of nooit dat ik me kan herinneren dat een systeem instabiel werd door een onverklaarbare reden.

Ik hoop dat het niet in de processoren zal komen. Kost meer energie want er zitten meer transistoren in. En mijn gevoel en ervaring zegt dat het zinloos is.

En als je dit al zou willen oplossen da zou IMO de processor een programma moeten afbreken als een legitieme instructie gevraagd wordt.

Ik vraag me af of je het echt gaat merken. Zoals ik het lees worden alleen onbekende commando's niet zomaar uitgevoerd. Het lijkt me een kleine moeite een klein stukje geheugen in te bouwen waarin onbekende, maar goed bevonden commando's (die vaak gebruikt worden) opgeslagen worden die in het vervolg zonder morren uitgevoerd worden.

Ja sorry hoor, maar omdat de processor steeds sneller wordt wil ik er ook van genieten, en dan moet er niet een onzinnige controle gedaan worden..

Jij wilt er van genieten, maar je bent waarschijnlijk gewoon een particuliere gebruiker. Wanneer je een server hebt draaien met een belangrijk doel, wil je niet dat deze crashed wanneer er een foutief commando wordt gegeven. Bij servers is stabiliteit namelijk ook zeer belangrijk en misschien nog wel belangrijker dan snelheid. Dus dit is zeker niet onzinnig in mijn ogen.

[Reactie gewijzigd door Jeff van Hees]


Dus als je een game hebt (of andere software), waar veel gebruik gemaakt wordt van een niet-geteste commandos, krijg je opeens een grote performace hit... Lekker dan :/

[Reactie gewijzigd door lordsnow]


Draai jij veel totaal ongeteste software? En wil je dat wel?

Je koop toch ook geen ongeteste auto maar eentje die goed is getest maar wel veilighedsgordels en airbags heeft. Voor 'onverwachte' situaties. Die maken je auto wel zwaarder en dus langzamer.

Een nogal kromme vergelijking. Een ongeluk met een auto is vaak gevaarlijk en heeft vaak lichamelijk of materiele schade tot gevolg. Dat moet uiteraard voorkomen worden, maar wel zodat de bestuurder nergens last van heeft. Je auto zal niet opeens afremmen of vertragen als er een mogelijke dreiging word geconstateerd. Bovendien als je processor crasht, wat voor schade kan er dan optreden? De kans op lichamelijk letsel is eigenlijk niet aanwezig, extreem bijzondere situaties uitgezonderd, en de kans dat je processor beschadigt is eigenlijk ook bijzonder klein. En bovendien heb je daar nog garantie op ook een tijd.

[Reactie gewijzigd door Tsurany]


Je auto zal zeker niet afremmen of vertragen, daar is de bestuurder voor, als het goed is.

Moderne Volvo's bijvoorbeeld die remmen zelf wel degelijk alvast een beetje.

Je auto zal niet opeens afremmen of vertragen als er een mogelijke dreiging word geconstateerd.
Niet zo krom als jij denkt. Wel eens van ABS gehoord? Die schakelt je remmen tijdelijk uit zodat je niet gaat slippen. Mogelijk gevaar dus


Of van Brake Assist? De auto merkt dat je snel wilt gaan remmen omdat jet het pedaal snel in trapt, maar niet ver genoeg om echt te hard te remmen. Hmmm er is mogelijk gevaar, dus wordt het door de auto zelf al harder geremd dan jij deed. Dat zit zelfs al in een Toyota Yaris. Wat duurdere auto's hebben Cruise Control die er voor zorgt dat je niet te dicht achter je voorganger komt. Hij remt dus af bij mogelijk gevaar.

En dan natuurlijk nog de dingen als

tractie control: Motor vermogen verminderen als je te snel optrekt

Vehicle Stability Control Hier worden remmen of gasgeven in bochten per wiel aangepast zodat je beter op de weg blijft. Je remt dus niet zo hard als je zou willen, of je trekt niet zo hard op als dat mogelijk gevaar zou geven

Autes vertragen en versnellen doorlopend als er gevaar dreigt. Ook al merk je het niet direkt
Bovendien als je processor crasht, wat voor schade kan er dan optreden? De kans op lichamelijk letsel is eigenlijk niet aanwezig, extreem bijzondere situaties uitgezonderd, en de kans dat je processor beschadigt is eigenlijk ook bijzonder klein. En bovendien heb je daar nog garantie op ook een tijd.
En dacht jij dat er geen processors zaten in medische apperatuur, vliegtuigen, energie centrales? Als daar iets mis gaat kan je knap veel lichamelijk letsel krijgen. Of wat dacht je van een voedingsmiddelen fabriek waar jouw eten vandaan komt. Dat heb je liever ook niet bedorven doordat er een processor crashte

De wereld draait niet alleen om een game computer bij iemand op zijn slaapkamer

[Reactie gewijzigd door Ortep]


Met mogelijke dreiging bedoel ik dreiging die kan ontstaan uit een voetganger die bijvoorbeeld langs de weg loopt. De kans is er dat hij de op de weg beland. Maar je auto gaat daardoor niet automatisch afremmen mocht dat gebeuren. De auto helpt je wel ja, maar dus niet zodat je het zelf merkt door langzamer te rijden als er iets kan gebeuren. Dat idee is het ook met de crash preventie, aangezien het niet zeker is dat hij door die code zou crashen, dat moet het programma namelijk eerst onderzoeken of hij zou crashen, en dat merkt je wel direct.

En voor die processoren in medische apperatuur en dergelijken is zoiets niet echt voor nodig, aangezien ze precies weten welke codes daarop uitgevoerd zullen worden, de kans dat daar onbekende code op word uitgevoerd is eigenlijk niet aanwezig. Medische apperatuur doet geen duizenden verschillende dingen, die doet een bepaald aantal dingen waar hij uitgebreid voor getest is. Net als een processor in een vliegtuig, die zal niet opeens nieuwe software krijgen die niet uitgebreid getest is en waar een fout in zit.

Met mogelijke dreiging bedoel ik dreiging die kan ontstaan uit een voetganger die bijvoorbeeld langs de weg loopt. De kans is er dat hij de op de weg beland. Maar je auto gaat daardoor niet automatisch afremmen mocht dat gebeuren. De auto helpt je wel ja, maar dus niet zodat je het zelf merkt door langzamer te rijden als er iets kan gebeuren.
Lees eens wat over auto's, er zal een wereld voor je open gaan. De 'afstand sensor' bij cruise control gaat wel degelijk fors afremmen als de auto voor je plots langzamer gaat. Dat is namelijk een dreiging, als je dat niet doet rijd je er tegen aan. Dat merk je heus wel.

En als je ooit eens zelf in een auto bestuurd met ABS moet je voor de lol eens vol op de rem staan. Dan merk je direkt dat hij ingrijpt. Je remt namelijk plotseling heel anders.

En deze vindt je vast ook heel leuk, nog niet in de handel, maar wel uitvoerbaar

http://www.nrc.nl/tech/ar...dt_straks_op_eigen_houtje
.... een Mercedes remde met piepende banden voor een overstekende voetganger – zonder dat de chauffeur iets hoefde te doen.

[Reactie gewijzigd door Ortep]


Dat is dus het hele punt, dan is er echt een dreiging, namelijk iemand die voor je afremd. Dat is een bekende dreiging die daadwerkelijk gebeurt en als daar niet op gereageerd word gaat het daadwerkelijk fout. In dit geval is dat niet zo, een deel van de te controleren code zal de processor niet laten crashen en het is dus niet nuttig dat je daar op moet wachten.
Kijk maar naar die link, "een mercedes remde met piepende banden voor een overstekende voetganger", dat is wat anders dan remmen omdat een voetganger die langs de straat loopt misschien zou kunnen oversteken.

En ik weet genoeg over auto's om al die systemen te kennen.

Wel eens van ABS gehoord? Die schakelt je remmen tijdelijk uit zodat je niet gaat slippen. Mogelijk gevaar dus

Maar heb je al eens nagedacht WAT je dan wil doen met de detectie van code die 'waarschijnlijk' niet deugt? (als zulke detectie al mogelijk is). Stel, je bent lekker in Word bezig of zo, of een willekeurig ander proces, en je CPU besluit tot een pre-emptieve "Danger,Will Robinson! Danger!" actie. Wat dan? Moet de CPU het stukje code dan maar gewoon overslaan? Dat gaat natuurlijk niet. En hoe langer ik er over nadenkt, des te meer zie ik eigenlijk maar 1 echte oplossing: een BSOD! Nee, serieus! Immers, het process dat je onderbreekt zou wel eens vitaal kunnen wezen voor iets anders. Voorbeeldje: als x264 blijft hangen, kan ook het bovenliggende render programma niks meer (of raakt in de war van het onverwachte resultaat). Je zult dus of met een "Program X stopped responding" error moeten komen, of gewoon banaal het hele systeem een halt toe moeten roepen met een blue-screen.

Mijn punt is in ieder geval, dat ik me afvraag wat je nou helemaal hebt aan zo'n detectie. In het vriendelijkste geval krijg je netjes een error-meldig, maar die krijg je nu ook al bij 'illegal instruction' errors. Kijk, je zou kunnen redeneren dat zo in ieder geval je server niet vastloopt; maar ja, zoals ik al betoogde, is dat dan wel zo wenselijk? 'Kernel panics' en "Program X stopped responding" errors zijn er niet omdat je OS zo onvriendelijk is om alles maar direct te stoppen, maar meer omdat je programma na zo'n lelijke CPU fout in een 'undeterminate' state geraakt. Stoppen is dan vaak toch wat het minste schade oplevert (denk aan data-corruptie bijv., als je toch door zou gaan).

Niet zo krom als jij denkt. Wel eens van ABS gehoord? Die schakelt je remmen tijdelijk uit zodat je niet gaat slippen. Mogelijk gevaar dus
Ik hoop dat je het anders bedoelt dan dat je het neerschrijft. ABS zorgt voor gepulseerd remmen zodat de wielen niet blokkeren. De remmen worden zeker NIET uitgeschakeld!!

Dat schreef ik toch? Tijdelijk...1/10 seconde of zo om daarna weer te remmen en weer uit te schakelen als het weer fout dreigt te gaan. Geen 10 minuten of zo. Je voelt hem 'stoten'

Maar dit gaat vreselijk off topic. Het gaat er om dat er meer systemen in het leven zijn die ingrijpen als iets fout dreigt te gaan en dat we de extra kosten, gewicht en vertragingen prima vinden.
En dat als een processor dat kan doen, dat best voordelen kan hebben.

[Reactie gewijzigd door Ortep]


ik weet niet waarom iedereen zich over de performancehit zorgen maakt.... het is een grotere performancehit als ik mijn pc/server OPNIEUW moet booten door een onbekende instuctie... Je werk zal er dus uiteindelijk effectiever en efficienter van worden. En je moet dit inderdaad als een autogordel zien: Het voorkomt dat de bestuurder door de voorruit vliegt als er een fout-optreed (botsing). Als ICT-Beheerder/Servicedeskmedewerker voor een groot bedrijf kan ik dat alleen maar toejuichen, wat als er een programmeur een uur bezig is geweest met het schrijven van een programma en (god-forbid) door het aanroepen van een foute functie zijn laatste SVN kwijt is...

Het punt is juist dat je niet zeker weet of de code daadwerkelijk foutief is voor je het controleerd, zou dus best kunnen dat er niks zou gebeuren en dan merk je wel de performancehit die er normaal niet zou zijn.

Het lijkt me niet iets wat op relatief korte termijn zijn weg zal vinden naar de desktop. Zoals in het artikel zelf al aangehaald, worden cpu bugs vaak in de bios opgelost. Hoe vaak komt het voor dat een pc crasht omwille van een dergelijke fout? Mijn gok is: niet al te vaak. Is de consument werkelijk bereid hiervoor meer te betalen?
Maar serverfabrikanten en beheerders van rekencentra zijn waarschijnlijk wel wat enthousiaster. Een hangende cpu of een rekenfout zijn daar werkelijk bedrijfskritisch.

Onbekende commando's, dus die niet in de instructie set staan?

Eerder instructies die op een ongebruikelijke manier worden gebruikt.
Er is sinds de tijd van de 6800 veel verandert hoor.

Ik vind het maar een vage vinding; ik heb geen harde cijfers, maar het lijkt me dat het gros van de crashes uiteindelijk komt door de context waarin een instructie wordt uitgevoerd waardoor de software niet meer overweg kan met het resultaat. Dat is dan misschien geen CPU vastloper maar die zijn sowieso relatief zeldzaam volgens mij. Een fout in de operands van een instructie kan natuurlijk ook, die, in bepaalde context. een fout veroorzaken in de CPU die een 'voorproever' natuurlijk niet kan weten. Verder zijn "onbekende commando's" sowieso niet echt mogelijk; dat zal bij voorbaat een exceptie veroorzaken in de CPU. De instructieset staat namelijk zo vast als een huis. Tenzij je de software van nieuwere CPU's op oudere draait, maar dat wordt veelal gevangen (de CPU exceptie) om daarna terug te vallen op een software versie ervan (is weliswaar trager maar hey, het werkt) of om een nette foutmelding te geven dat instructie X niet ondersteund wordt.

Ik moet het nog zien.

[Reactie gewijzigd door RobIII]


Het komt bij mij toch als een behoorlijk wazig verhaal over. "Wanneer een niet-getest commando wordt gesignaleerd," is een uitspraak die je verwacht van iemand die er geen verstand van heeft. Simpelweg, wanneer er normaalgesproken een niet-getest commando wordt gesignaleerd krijg je een INT 06 (illegal opcode). Dat kan, als je zelf iets assembleert bijv, en bewust opcode bits aanzet die gereserveerd zijn, of die gewoon geen geldige code opleveren. Of door 'runaway' code, uiteraard.

Wat de auteur dus wel zal bedoelen, is zoiets als: "Wanneer er zich een conditie voordoet die onverwacht is." Dat is al beter. Maar, zoals die Brookwood dus al zegt, het is natuurlijk twijfelachtig of je dat soort condities echt kunt traceren; immers, als de CPU al doorhad dat het echt mis was, dan zou ie die conditie al niet laten gebeuren! Zoiets als die AMD cache bug is een goed voorbeeld: daar ging onder een combinatie van bepaalde omstandigheden wat mis met de cache; maar dus -- uiteraard, zou ik haast zeggen, het ging mis als 'bug' -- de CPU had het dus zelf niet door. Daar is het dus een bug voor!

Dus, 'instructie-tester' is iets wat ik, vooralsnog, gooi op hetzij slechte vertaling, hetzij onbegrip met de materie. Het moet wel haast een stuk gecompliceerder zijn dan Koevoet het hier voorstelt.

Vreemd verhaal dit artikel, klinkt handig natuurlijk, maar hoe vaak gaat deze vlieger nu echt op.

Ik zou eigenlijk gewoon verwachten dat de CPU werkt volgens de specificaties zonder problemen, mits het ontwerp door verantwoordelijke ontwerpers is gemaakt.

Ik denk dat de hier geschetste truc ook wel ooit door intel of amd verzonnen is en ook geimplementeerd is.

Het klinkt een beetje als een broodje aap verhaal.

Ik vraag me af hoe het in de gamers wereld zal gaan werken.
Ik vind het niet leuk als ik ineens een framedrop krijgt omdat mijn spelletje moet worden voorgeproefd.

Enuh, hoe bepalen ze dus waar dus op getest moet worden, leuk als er per ongeluk dus een fout wordt gemaakt in dus valid commando's ineens als onveilig worden gezien..
Laat dat maar achterwege, want daarmee kan alleen nog maar meer fout gaan, en dus weer een niveau wat extra goed getest moet worden.. en kom op zeg hoe vaak komt het nou werkelijk voor, zelden....

Ik begrijp iets niet.... als er dus een "verkeerd commando/instructie naar de CPU gaat, gaat deze in veilige modus draaien. Waarom heeft de CPU er dan geen last van als het in die modus draait?
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 18:55
Vorige 17:36
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: