gibt es eigentlich AS400 VIREN oder WÜRMER ?

[Fuerchau]

Auf der AS, egal mit welchem Compiler oder in welcher Umgebung, wird NIEMALS Native-Prozessor-Code generiert.
Da das Grundprinzip ja das MI (Maschinen-Interface) ist, würde jede Übertragung auf eine andere Hardware zu einem Recompile (was Quellen voraussetzt) führen müssen. Dies ist seit jeher das Problem von z.B. UNIX/LINUX. Ich habe nur eine sog. Source-Kompatibilität (und auch nicht immer).
Ich habe also keine Chance, die CPU direkt anzusprechen.
Auch das Patchen von Objekten hilft da nur eingeschränkt.

MI ist nahezu vergleichbar mit dem generierten Java-Code. Auch dieser ist (fast) auf jeder JVM ausführbar unabhängig von der Hardware-Plattform.

Nicht umsonst setzt die IBM ja nach AS-Model auch unterschiedliche CPU's ein. Auch auf einer i5 kann ich noch Programme für V5R1 erstellen.

Zur Laufzeit ist auch der sog. ausführbare Code gegen Zugriffe gesperrt.

[BenderD]

Hallo,

so langsam gleitet die Diskussion ab ins unpräzise. Bisher scheint es ja unisono für möglich zu erachten, dass es Würmer auf einer AS400 geben kann (und Trojaner sowieso).
Also zu den Viren: was sind überhaupt Viren? Rein technisch sind das erstmal Programme, die andere Programme infizieren und ihre eigene Funktionalität in das nun infizierte Programm einfügen. Das unangenehme an diesen Teilen ist also, dass ich mit fortlaufender Durchseuchung immer größere Probleme habe den Schmutz wieder loszuwerden.
Für die meisten Betriebssysteme sind Programme auf der Ebene der Plattenverwaltung nix anderes als Streamfiles, in die ich beliebiges einkopieren kann (mit dem Risiko, dass das Programm sofort kaputt ist, ein Virenprogrammierer muss also mehr können als kopieren!). Hier hat nun die AS400 zunächst den Vorteil, dass auf der Ebene der Plattenverwaltung (genauer in user domain Objekten) eben doch was anderes als Streamfiles sind. Diese Klippe ist für den Ungeübten sicher hoch genug, aber eben keinerlei Sicherheit dafür, dass sie nicht bereits jetzt von etlichen übersprungen werden könnte und sicherlich wenige Monate, wenn nicht eher Wochen ausreichen sich die Kenntnisse zu erarbeiten.
Eine kleine PowerPC Assembler Routine (eine Art Dreizeiler) reicht aus, diese Hürde zu knacken, Hardwareabhängigkeit von sowas ist kein Argument, das gilt für alle anderen Plattformen erstrecht, man fragt als erstes einfach: "welchen Prozessor hast Du eigentlich?" Die Assembler Routine ist freilich auch Bestandteil des Virensegmentes, kann also nicht separat gefunden und entfernt werden. Dies ist nur einer von mehreren Möglichkeiten...

mfg

Dieter Bender

Auf der AS, egal mit welchem Compiler oder in welcher Umgebung, wird NIEMALS Native-Prozessor-Code generiert.
Da das Grundprinzip ja das MI (Maschinen-Interface) ist, würde jede Übertragung auf eine andere Hardware zu einem Recompile (was Quellen voraussetzt) führen müssen. Dies ist seit jeher das Problem von z.B. UNIX/LINUX. Ich habe nur eine sog. Source-Kompatibilität (und auch nicht immer).
Ich habe also keine Chance, die CPU direkt anzusprechen.
Auch das Patchen von Objekten hilft da nur eingeschränkt.

MI ist nahezu vergleichbar mit dem generierten Java-Code. Auch dieser ist (fast) auf jeder JVM ausführbar unabhängig von der Hardware-Plattform.

Nicht umsonst setzt die IBM ja nach AS-Model auch unterschiedliche CPU's ein. Auch auf einer i5 kann ich noch Programme für V5R1 erstellen.

Zur Laufzeit ist auch der sog. ausführbare Code gegen Zugriffe gesperrt.

[Fuerchau]

Ich glaube nicht, dass du in ein PGM-Objekt (kann man ja per /qsys.lib ggf. bearbeiten) nativen Prozessor-Code einfügen und dann auch ausführen kannst.
Basis der AS für ALLE ausführbaren Objekte ist und bleibt die MI-Ebene.

Dass man PGM-Objekte auch als Datei behandeln kann zeigt ja bereits der SAV-Befehl. Wie sonst kann man denn alle Objekte sichern als als Stream.

[BenderD]

Hallo,

wenn das nicht ginge, dann könnte man das MI nicht implementieren, abgesehen davon würde wohl pase schon reichen (derselbe Ansatz mit Prozessor abhängigem Code!!!).

Das mit der Behandlung beliebiger Objekte als Streamfile ist in den APIs Objekt abhängig abgefangen, aber hier gibt es in der Tat einen weiteren Ansatz; SaveFiles haben zwar eine Art Zeilensignatur, aber die dürfte angreifbar sein (wieder mal amerikanische Exportrestriktionen und IBM).

Dieter

Ich glaube nicht, dass du in ein PGM-Objekt (kann man ja per /qsys.lib ggf. bearbeiten) nativen Prozessor-Code einfügen und dann auch ausführen kannst.
Basis der AS für ALLE ausführbaren Objekte ist und bleibt die MI-Ebene.

Dass man PGM-Objekte auch als Datei behandeln kann zeigt ja bereits der SAV-Befehl. Wie sonst kann man denn alle Objekte sichern als als Stream.

[Fuerchau]

Sind also mittels PASE erstellte Pgme nicht MI-orientiert ?
Dies würde ja bedeuten, dass ich mit jedem neuen Prozessor die Objekte neu erstellen muss (also die Quelle da sein muss).
Ich dachte (wohl falsch), dass auch die Pase/Linux-Implementierung auf MI aufsetzt und somit Prozessorunabhängig ist.

[BenderD]

@Baldur,

Pase Programme sind nicht binär kompatibel cross Prozessor. Was da so auf MI aufsetzt und was nicht, da glaube ich dem Marketing nix mehr; seitdem ich mal auf die Frage (bei V4R2) ob die Java Implementierung eine AIX Portierung sei zur Antwort bekam, das ginge garnicht und kurz später kam Pase als Lic Produkt raus. Die ganzen JVM Bildchen mit MI und TINI und hastenichtgesehn waren möglicherweise alles Schmonz.
Auch AS400 Programme müssen nicht binär kompatibel sein, solange man den (teilweise) recompile nicht merkt, weiss man nicht was da wirklich passiert.
Pase und Linux lenken angeblich einige direkte Hardware Interrupts auf MI level um, um die Kontrolle über die Hardware zu behalten, aber wieweit das stimmt und wenn es denn stimme auch wieder umgeknipst werden kann, steht auf einem anderen Blatt.

Dieter

Sind also mittels PASE erstellte Pgme nicht MI-orientiert ?
Dies würde ja bedeuten, dass ich mit jedem neuen Prozessor die Objekte neu erstellen muss (also die Quelle da sein muss).
Ich dachte (wohl falsch), dass auch die Pase/Linux-Implementierung auf MI aufsetzt und somit Prozessorunabhängig ist.

[Sven Schneider]

Zum Thema Pase :
Pase Programme werden im IFS (QOPENSYS) abgelegt und sind damit manipulierbare Streamfiles.
Ich kann sie mit einem AIX-Compiler unter pase auf der AS/400 oder auch unter AIX erstellen.
Es werden in beiden Fällen nativ Risc-Power Code erzeugt.
Diese wäre nicht portabel, falls sich die Hardwareplattform ändert (RISC --> ???)
Es läuft nur das unter pase-Kontrolle, was auch unix-API's benutzt, weil diese Aufrufe werden auf diePase-runtime umgeleitet.

Zum Thema MI oder beliebiges PGM-Objekt:
Egal welches PGM-Objekt unter OS/400, es wird intern immer ein Programm template und der binäre Power-RISC-Code gemeinsam im PGM-Objekt abgelegt. Deshalb sind diese PGM-Objekte auch von Hause aus etwas größer als auf anderen Plattformen.
Der HLL-Compiler/Linker erzeugt den plattformunabhängigen internen Zwischencode (programm template) auf MI-Ebene.
Der IBM-Translator erzeugt zusätzlich den ausführbaren Power-RISC-Code, mit exakt definierten RISC-Instructionen.
Hier kann ich halt nicht eingreifen.

Gibt es nun irgend wann einen Plattformwechsel, wird auf der Zielplattform nur der Translator (STROBJCVN) angeschmissen und aus dem template der neue ausführbar Binärcode erzeugt.

Ab Version V5R1 kann ich zusätzlich die observabilty Daten (nichts anderes als das programm template) entfernen und trotzdem lässt sich des Objekt vom Translator neu erstellen.
Es wird ein komprimierte Format des programm templates weiterhin gespeichert.
Es ist aber damit schwieriger den Source-Code aus dem Programmobjekt zu rekompilieren. (laut IBM besser Schutz für ISV's)

Java ist wieder ein eigenes Thema :
die JVM ist im SLIC implementiert, also unterhalb der MI.
Java-PGM-Objekte bestehen aus einem (internen nicht sichtbarem)PGM-Objektteil und dem Java-Byte Code im IFS.
Der PGM-Objektteil existiert nur, wenn ich CRTJVAPGM auf eine Java-Klasse ausführe. Es wird hier ein optimierter plattformspezifischer RISC-Code erzeugt.
Beim Save/Restore wird ein vorhandenes Java-PGM-Objekt mit berücksichtigt.

Dazu gibt es ein gutes Buch von Frank Soltis. (Inside ...AS/400 ... ?!)