Hallo, http://www.dguv.de/ifa/de/pub/rep/pdf/rep05/biar0706/Report7_2006.pdf Seite 36-37, betreffend XRAM_TEST2 Mir ist die vorgeschlagene Vorgehensweise unklar. Ändern eines Bytes im RAM mit anschließender Signaturüberprüfung soll doch gerade eine abweichende Signatur erzeugen. Das Ziel der Prüfung soll die Aufdeckung der Kurzschlüsse der Speicherzellen sein. Gruß, Daniel
ich glaube ich hab's: das veränderte Byte fliesst nicht in die Signaturberechnung mitrein! that makes sense
@daniel diese publikation ist schlichtweg halbwissender mumpitz in grossen teilen (PC test z.B., ick schmeiss mich weg lol). der/die verfasser haben hoffentlich noch nie ein sicherheitsrelevantes system entworfen, sondern nur aus 13 den 14. schriebs generiert... ALU und SFR tests sind auch in dieser kategorie anzusiedeln... zum stichwort RAM-Test, schau mal nach BIST und marching pattern tests im inet, da wirst du fündig. einfaches 0x55/0xaa pattern schreiben/lesen tut es nämlich nicht. bei der implementierung wirst du auf assembler zurückgreifen müssen und möglichst schnellen code erzeugen, je nach RAM-grösse dauert das mal ganz schnell etliche msecs für den kompletten pattern-durchlauf und das sollte vor dem startup-code des C-programmes ausgeführt werden. gruss+viel erfolg in diesem interessanten bereich ! tom.
hi Tom tom schrieb: > diese publikation ist schlichtweg halbwissender mumpitz in grossen > teilen (PC test z.B., ick schmeiss mich weg lol). der/die verfasser > haben hoffentlich noch nie ein sicherheitsrelevantes system entworfen, > sondern nur aus 13 den 14. schriebs generiert... > ALU und SFR tests sind auch in dieser kategorie anzusiedeln... dass SFR und Port Tests heikel werden können, kann ich nachvollziehen Schliesslich können sie irgendwelche externe Ereignise anstossen. Aber warum macht es wenig Sinn PC auf seine Inkrementfähigkeit zu testen? Die Literatur scheint es in diesem Bereich uC Sicherheitsbereich sehr dünn zu sein. Eigentlich wäre es die Aufgabe der uC Hersteller ASM Routinen für bestimmte Tests bereitzustellen. Schliesslich haben nur sie das Wissen über Interna und welche Reihenfolge von Tests mehr Sinn macht (damit die Fehlerdiagnose präziser wird) Gruß
Daniel schrieb: > Eigentlich wäre es die Aufgabe der uC Hersteller > ASM Routinen für bestimmte Tests bereitzustellen. ordentliche uC - Hersteller tun dies bereits: schau mal nach AN1229 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en537355 Gruß Anja
Daniel schrieb: > Aber warum macht es wenig Sinn PC auf seine Inkrementfähigkeit zu > testen? Was glaubst du, wird deine Testroutine so veranstalten, wenn der PC nicht inkrementfähig ist? Richtig, alles Mögliche, nur nicht den konzipierten Test. Sowas kannst du praktisch nur durch einen Watchdog-Reset abfangen, wobei der Watchdog "von außen" (also ohne Zutun der Firmware) aktiviert werden muss, damit er nicht selbst vom funktionierenden PC abhängig ist. Bei einem AVR beispielsweise wäre das durch Programmieren der entsprechenden Fuse (WDTON) der Fall. Im Großen und Ganzen erscheint mir das viel Aufwand für Dinge, die in der Praxis kaum Relevanz haben. Die meisten praktischen Ausfälle wirst du dadurch haben, dass entweder starke elektromagnetische Felder auf das Gerät einwirken und Signale zu stark deformieren, oder dass Betriebsspannungen kurzzeitig oder längerfristig so weit zusammenbrechen, dass gehaltene Daten verfälscht werden oder die Ausführungslogik sich nicht mehr so verhält, wie sie sollte.
Jörg Wunsch schrieb: > Im Großen und Ganzen erscheint mir das viel Aufwand für Dinge, die > in der Praxis kaum Relevanz haben. Der Aufwand ist schon gerechtfertigt. Du möchtest ja schließlich nicht bei 180 auf der Autobahn den Airbag sehen nur weil der Rechner (einer von zig Millionen) einen Maskenfehler hat und bei einer Multiplikation eine falsche Beschleunigung berechnet wird. Gruß Anja
Jörg Wunsch schrieb: > Im Großen und Ganzen erscheint mir das viel Aufwand für Dinge, die > in der Praxis kaum Relevanz haben. Der POST (Power On Selftest) des IBM PC von 1981 prüfte genau die Dinge, die im oben verlinkten Bericht in Kapitel 2 ... 4 beschrieben sind. Ich denke, daß der POST durchaus das Ergebnis langjähriger Erfahrung und eines sorgfältigen Designs ist. Dementsprechend sehe ich hier durchaus eine sinnvolle Funktion. Bernhard
Anja schrieb: > Jörg Wunsch schrieb: >> Im Großen und Ganzen erscheint mir das viel Aufwand für Dinge, die >> in der Praxis kaum Relevanz haben. > > Der Aufwand ist schon gerechtfertigt. Du möchtest ja schließlich nicht > bei 180 auf der Autobahn den Airbag sehen nur weil der Rechner (einer > von zig Millionen) einen Maskenfehler hat und bei einer Multiplikation > eine falsche Beschleunigung berechnet wird. Ein Maskenfehler ist per Definition ein Serienfehler, oder nicht? Und eine Multiplikation ist kein gutes Beispiel, siehe FDIV-Bug im Pentium. Man müsste schon alle möglichen Operandenkombinationen testen um sowas festzustellen - nicht direkt praxistauglich, selbst Intel mit all ihren Milliarden Dollars kann sowas offensichtlich nicht machen. In der Praxis würde man das anders lösen: N Rechner, mit verschiedener Hardware und unabhängig implementierter Software. Sind alle Ergebnisse identisch, stimmt das ziemlich wahrscheinlich, sonst ist es suspekt. Und nein, soviel ist unser Leben den Autoherstellern wohl nicht wert, ist eher Luft-/Raumfahrt und Tötungsmaschinerie... :-(
Bernhard R. schrieb: > Jörg Wunsch schrieb: >> Im Großen und Ganzen erscheint mir das viel Aufwand für Dinge, die >> in der Praxis kaum Relevanz haben. > > Der POST (Power On Selftest) des IBM PC von 1981 prüfte genau die Dinge, > die im oben verlinkten Bericht in Kapitel 2 ... 4 beschrieben sind. Mit dem Unterschied, dass dort alles extern zusammengestöpselt war und nicht von vornherein klar war, ob die eingesetzten RAMs am Ende überhaupt in der Lage sind, im Gesamtdesign in ihren Parametern ausreichend Reserven beim Timing etc. zu haben. All das kann man bei einem Microcontroller als gegeben annehmen, denn das hat der Hersteller während der sogenannten Bauteilequalifikation bereits nachweisen müssen. Nur, weil IBM mal irgendwas irgendwie getestst hat, daraus zu schluss- folgern, dass dieses auch sinnvoll war, ist sowieso an den Haaren herbeigezogen. Wie oft ist denn jemals ein PC stehengeblieben mit einem POST error, weil sich der PC "nicht mehr inkrementieren" ließ? Ich will mich ja auch nicht gegen jegliche Tests aussprechen, aber man sollte sich sinnvolle und praxisrelevante Tests überlegen. Dazu gehört als erstes eine Ausfallanalyse, damit man seinen "Gegner" kennt. Erst dann kann man sinnvolle Gegenmaßnahmen entwerfen, wobei man stets überlegen muss, ob der Test angesichts der zu testenden potenziellen Schädigung überhaupt noch eine Chance hat, selbst lauffähig zu sein. Ein RAM-Test wird da wohl noch vergleichsweise einfach sein, wenn man ihn nur so schreibt, dass er rein mit Registern arbeitet und selbst keinen RAM braucht. Eine CRC über den (Flash-) ROM ist auch einfach, denn wenn irgendwo ein Bit gekippt ist, ist die Wahrscheinlichkeit recht hoch, dass es nun nicht gerade mitten in der CRC-Test-Routine selbst ist. Ein Test auf "Inkrementierbarkeit des PC" ist jedoch so ziemlich das Absurdeste, was man sich vorstellen kann. Wenn die grundlegenden Register des Prozessors so weit im Eimer sind, dann läuft da drin nur noch irgendetwas ab, was keinerlei Ähnlichkeit mehr haben wird mit dem, was sich der Entwickler mal ausgedacht hat. Sofern man nicht einen kompletten zweiten Satz Register (einschließlich PC natürlich) hat, ist das witzlos. Ergo muss man sich notwendig Gedanken machen, wie man derartige Szenarien von außen (außerhalb der CPU) erkennt und unschädlich macht. Gängig dafür sind halt Watchdogs in allen Ausprägungen, denn diese laufen komplett neben den Ressourcen der eigentlichen CPU und des Controllers (eigener Taktgenerator, eigener Zähler). OK, man könnte noch beim Start überwachen, dass der Watchdog auch wirklich einen Reset auslösen kann und nicht etwa seine Reset- Leitung kaputt ist ...
Bernhard R. schrieb: > Der POST (Power On Selftest) des IBM PC von 1981 prüfte genau die Dinge, > die im oben verlinkten Bericht in Kapitel 2 ... 4 beschrieben sind. Dieser überprüft aber nur Peripherie, die sich nicht mit im CPU-Chip befindet. Mit einem Test von Ressourcen auf dem Chip selber belügst Du Dich nur selbst. Du weißt nicht, was man da testen könnte und wie. Es sei denn, der Chiphersteller gibt Dir eine von ihm beglaubigte Test-Suite, denn nur er kann wissen, was wie ausfallen könnte. Deine selbst erdachten Tests werden also um Größenordnungen untauglicher sein, als jeder Test des Herstellers im Werk. Daß ein Chip andere angeschlossene Chips testet hat den Grund, daß vor allem die Lötstellen die Zuverlässigkeit drastisch herabsetzen. Deshalb wurden auch die integrierten Schaltkreise entwickelt. Nicht um Platz, Strom oder Kosten zu sparen, sondern hauptsächlich, um die Anzahl der Lötstellen zu reduzieren und damit die Zuverlässigkeit zu erhöhen. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.