Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 64 reacties

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.

Moderatie-faq Wijzig weergave

Reacties (64)

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.
Probleem met dit systeem is wel dat er dus omwegen worden gecrerd waardoor foute code uiteindelijk goed wordt uitgevoerd.

Het is een beetje net als met IE en firefox. IE accepteert heel veel foute code en hierdoor zijn webdevelopers vaak erg makkelijk omdat het onder IE tch wel werkt. Komt er iemand met firefox of opera die wl aan de specificaties voldoet, dan werken die halve flash-java menubalkjes ineens niet meer en staat alle tekst ineens op elkaar gedrukt. Roept de gemiddelde mens meteen dat firefox slecht is omdat het in feite dus gewoon geen foute code accepteerd.

Straks krijg je slechte geprogrammeerde code en gaat jouw normale pc'tje op zijn gat en je crash-beveiligde pc draait lekker door. Tja, maakt dat dan ineens jouw oude vertrouwde pc'tje slecht of zit het 'm in de programmeur?

Ik denk dat je zo'n systeem niet eens wlt hebben, tenzij je bij elke fout een melding krijgt of een piep uit de speaker, dan kan wordt de programmeur in ieder geval ertoe gedwongen zijn code te herzien.
Roept de gemiddelde mens meteen dat firefox slecht is omdat het in feite dus gewoon geen foute code accepteerd.
Maar dat is toch ook zo? Een browser moet niet een standaardenchecker spelen maar een pagina zo goed mogelijk renderen, of die pagina nou aan de standaard voldoet of niet.
Het gaat bij deze "verkeerde commandos" om byte-sequenties die niet in de officiele instructieset van de processor zitten maar waar de processor toch iets onverwachts mee doet. Dit is iets dat door crackers bijvoorbeeld misbruikt kan worden om code met verhoogde privileges uit te voeren zodat bijvoorbeeld een virus zich alsnog met systeemrechten kan installeren terwijl je met een gewone gebruikersaccount aan het werken bent. Dit is iets waar de processorfabrikanten nu langzaamaan bescherming tegen willen gaan inbouwen.
Het gaat bij deze "verkeerde commandos" om byte-sequenties die niet in de officiele instructieset van de processor zitten maar waar de processor toch iets onverwachts mee doet. Dit is iets dat door crackers bijvoorbeeld misbruikt kan worden om code met verhoogde privileges uit te voeren zodat bijvoorbeeld een virus zich alsnog met systeemrechten kan installeren terwijl je met een gewone gebruikersaccount aan het werken bent. Dit is iets waar de processorfabrikanten nu langzaamaan bescherming tegen willen gaan inbouwen.

Nee, dat is echt onjuist. Byte-sequenties die niet in de officiele instructieset van de processor zitten zullen nooit ofte nimmer worden uitgevoerd omdat.. ze niet in de officiele instructieset van de processor zitten! Die zullen altijd een 'illegal opcode' error genereren.

Waar jij waarschijnlijk op doelt, is dat je wel eens iets gelezen hebt over 'specially crafted code' en zo, om verhoogde privileges te krijgen. Maar wat daar doorgaans mee bedoeld wordt, is code die specifiek geschreven is om, zeg, een buffer-overrun te creeren. Wat er dan 'speciaal' aan dat soort code is, is dat de cracker de bewuste buffer precies zo over laat lopen dat bestaande code, op de juiste plaats, overschreven wordt met de zijne, zodat een privilege escalation exploit mogelijk is. Er is verder niets speciaals aan dat soort code; en het betreft zeker niet "byte-sequenties die niet in de officiele instructieset van de processor zitten". Typisch gevalletje klepel en klok, dus.
Feitelijk onjuist. Er zijn genoeg "byte-sequences" bekend die niet officieel zijn en toch worden uitgevoerd. Zo kon/kun je een negatieve index gebruiken bij het lezen of schrijven van model-specific registers van de P6 cores, terwijl deze officieel positief moet zijn. Ook de SALC instructie was ongedocumenteerdm, net zoals de algemene vorm (2de byte <>0Ah) van de AAM/AAD instructies.
Feitelijk onjuist. Er zijn genoeg "byte-sequences" bekend die niet officieel zijn en toch worden uitgevoerd.

Zoals ik eerder al zei, zijn er genoeg bits en bytes te vinden die 'reserved' zijn, en die hetzij geen functie hebben, hetzij dus een undocumented functie hebben: ongedocumenteerd naar ons toe, wel te verstaan. Zo wist Intel best van het bestaan van SALC (Set Carry flag in AL) af, maar vond het kennelijk niet nodig om te vermelden.

Ook de tweede Operand in AAM/AAD is niks onofficieels. Het was alleen zo dat Intel deze inctructies oorspronkelijk 'one-byte' opcodes noemde, terwijl dat feitelijk niet zo is: het zijn twee-byte opcodes, waarbij het tweede byte de divisor is: D4 0A , dus, voor AAM, waarbij 0A dus 10 is, decimaal. Dat kan iedere willekeurige waarde zijn tussen 0 en FF. De reden waarom Intel dat niet vertelde zal wel zijn, denk ik, dat het resultaat van AAM (ASCII Adjust after Multipy) natuurlijk drastisch verandert wanneer je een andere deler kiest (omdat AL niet meer door 10 gedeeld wordt, met het quotient in AH en de rest in AL). In het officiele Pentium User's Manual staat deze werking nu echter ook gewoon weer als volgt gedocumenteerd:

"Note: imm8 has the value of the instruction's second byte. The second byte under normally assembly [sic] of this instruction will be 0A, however, explicit modification of this byte will result in the operation described above and may alter results."
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 op 1 oktober 2008 18:26]

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.
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 op 1 oktober 2008 19:04]

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 op 1 oktober 2008 19:35]

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 1s, 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.
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 op 1 oktober 2008 22:00]

Je hebt meer capaciteit nodig = grotere CPU of extra CPU die berekingen doet
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.
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 Jeffrey v. Hees op 2 oktober 2008 09:24]

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.
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 op 1 oktober 2008 19:07]

Tja, er is 1 groot voorbeeld bekend van een bug die op deze manier gevonden zou zijn: de Intel F00F bug. Maar aangezien dit zo'n heel nieuw concept is, lijkt het me veel waarschijnlijker dat in de eerste paar generaties er meer fouten in de "voorproever" zitten. Leuk, als die dan Windows afsluit omdat ie ten onrechte denkt dat Windows iets fout doet. Grote kans om sterk negatieve resultaten, kleine kans op beperkte goede resultaten.
Ik vraag me af of zoiets berhaupt wenselijk is. Stel je hebt een programma welke je CPU laat crashen, dat kan heel vervelend zijn, maar je weet in ieder geval dat dat door dat programma komt. Je kunt het dan (laten) fixen of kiezen een ander programma te gebruiken.

Met deze oplossing wordt je CPU trager (zeker als de 'bug' ergens in een loop staat) en heb je voor de rest niets in de gaten. Hoe kom je er dan achter dat dit aan de hand is?
Er zal wel een logfile worden bijgehouden met de "crashes" van dit controle-programma en hoogstwaarschijnlijk dan ook een melding voor de gebruiker. Lijkt me toch beter dan dat je cpu vastloopt.
Spijtig van het performance-verlies natuurlijk maar laat ze eerst maar wat testen/benchmarken voor ik daar uitspraken over doe...
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 op 1 oktober 2008 18:23]

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 op 1 oktober 2008 19:02]

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 op 1 oktober 2008 19:51]

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 op 1 oktober 2008 22:24]

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 op 1 oktober 2008 22:23]

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.
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True