www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR invalid opcode trap?


Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben sie nicht. Speicherzugriffsschutz auch nicht.

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Aehh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, daß das Programm selbst die größte Sicherheitslücke 
darstellt.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig.

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.