Gast
#1375016
Hallo, haben uC von Atmel diesen trap bzw interrupt slot? ich finde dazu kein statement. dieses feature ist doch eine Art Prerequisite für sicherheitsrelevante Systeme. Grüsse
Haben sie nicht. Speicherzugriffsschutz auch nicht.
Gast
#1375040
Danke für die schnelle Antwort. Schliesst das auch Xmegas mit ein? Wie sieht es mit mp430 und PICs aus? Gerade die letzteren sind doch recht zahlreich und aktuell .. 16, 32 bit.
Gast
#1375043
> eine Art Prerequisite für sicherheitsrelevante Systeme.
So lange man nicht in den Speicher schreibt, wo das Programm liegt, ist
ein Opcode-Check überflüssig. Und bei einer Harvard-Architektur trifft
das ja in der Regel so zu.
Bei ARMs gibt es das beispielsweise. Speicherzugriffsschutz ist aber auch da bei den vollintegrierten Controllern nicht existent. Und der ist, wenn man schon solche Kriterien anlegt, weit wichtiger.
Gast
#1375050
Die meisten modernen Controller haben den Command-Byte-Raum dicht gefuellt und haetten gerne noch mehr Commands. Was bedeutet es gibt eigentlich keine ungueltigen OpCodes. Wenn man so ein sicherheitsrelavantes Feature haben moechte, so sollte der Command-Byte-Raum eher duenn gefuellt sein, sodass ein falsches Bit mit sehr hoher wahrscheinlichkeit zu einem ungueltigen OpCode fuehrt. Falls sich nun ein controller fginden laesst, der genau ein ungueltiges commandbyte hat, so kann der noch nicht als sicherheits-controller dienen.
Gast
#1375065
>> eine Art Prerequisite für sicherheitsrelevante Systeme. >So lange man nicht in den Speicher schreibt, wo das Programm liegt, ist >ein Opcode-Check überflüssig. Und bei einer Harvard-Architektur trifft >das ja in der Regel so zu. Naja, man selbst schreibt da nicht rein, aber ein böser a,b Partikel, das an der Si Oberfläche streift, und so die gewöhnliche 4 FET SRAM Zelle umkippt, kann böse Folgen haben. Und ich glaube kaum, dass radiation hardened NASA SRAM Zellen in irgendeinem uC verbaut werden. @ Aehh das ist sicher ein Problem, das Du ansprichst.
Ich denke, daß das Programm selbst die größte Sicherheitslücke darstellt.
Gast
#1375078
>Ich denke, daß das Programm selbst die größte Sicherheitslücke >darstellt. Das tut nur was der Programmierer sagt. Und damit ist ER die Sicherheitslücke ;)
Richtig.
Gast
#1375082
>Ich denke, daß das Programm selbst die größte Sicherheitslücke >darstellt. auf dem Meeresniveau zweifelsohne. Die Frage ist wielange noch, bei ever-schrumpfenden Kanalbreiten/Strukturen. Habe ein schönes kleines Buch "Fault Tolerance Techniques for SRAM based FPGAs". Es geht da zwar um FPGA, aber die SRAM Problematik ist natürlich dieselbe. Die Elektronik im Liqvidator-Fahrzeug im Kraftwerk müsste auch ziemlich Fehlertolerant sein.
Gast
#1375091
ahja 8088 und 8068 hatten beide keinen invalid opcode trap ab dem 286 ist es drin. Quelle: Tannenbaum : Sein Minix3 Buch. Das ist der Grund für das vorhandensein des Signals SIGILL. Kann natürlich bei entsprechnender HW-Unterstützung der CPU gemeldet werden. Bin gerade nicht unter Linux .. aber werde mal eine executable mal verändern :) Ahja, wenn eine HD kaputt ist, könnte das auch locker passieren.
Gast
#1375379
Für den normalen Speicher hat man da eher einen Parity check. Wenn es um eine gewisse Sicherheit gehen Beta Strahen und ggf. Müonen oder ähneliche Teilchen, dann hilft es schon wenn man keinen so modernen µC nimmt, sondern einen mit größeren Struckturen. Gegen Alphastrahlung hilft das Gehäuse. Wobei auch schon ziehmlich viel Energie dazu gehört eine SRAM Zelle zu Stören. Der Flash bzw. EEPROM Speicher ist da wohl eher da Problem, und beim AVR ist das Programm im Flash, nicht im SRAM. Wenn man Probleme mit dem SRAM kreigt, kommt man auch in den Bereich wo man sich um einen Latchup durch Strahlung kümmern muß.