Java Virtual Machines (JVM) sind Software-Programme, die Hardware und Betriebssysteme abstrahieren, indem sie Programmen eine virtuelle Betriebssystem- und Hardware-unabhängige Schicht zur Verfügung stellen. „Write once, run everywhere“ war einst der Slogan.
Eine JVM ist somit eine Software. Aber ist eine Java Virtual Machine auch eine SOUP? Antworten finden Sie in diesem Beitrag.
JVM: Die ursprüngliche Idee
Eine Java Virtual Machine erlaubt es, dass Anwendungsprogramme weitgehend unabhängig von der Hardware und dem Betriebssystem entwickelt und kompiliert werden können. Entwickler schreiben Source-Code in einer der Programmiersprachen für die JVM wie Java, Jython, JRuby, Scala oder Kotlin. Sie kompilieren den Quellcode zu Class-Dateien. Dieser sogenannte Bytecode wird dann von einer Java Virtual Machine (JVM) interpretiert. JVMs sind für viele verschiedene Betriebssysteme verfügbar, die wiederum auf einer bestimmen Hardware laufen.
Die Java Virtual Machine dient somit als Abstraktionsschicht zwischen Betriebssystem und der eigenen Software.
Zu den wichtigsten Herstellern von Java Virtual Machines zählen:
- Oracle
- IBM
- JRockit
- Android Runtime
Ist eine JVM eine SOUP?
Ob eine Java Virtual Machine eine SOUP ist, hängt davon ab, ob sie Teil des Medizinprodukts ist oder Teil der vorausgesetzten Laufzeitumgebung.
Ob die JVM eine SOUP gemäß IEC 62304 ist, hängt davon ab, ob der Hersteller sie als Teil seines Produkts in Verkehr bringt.
Eine JVM ist nur dann eine SOUP, wenn sie Teil des (ausgelieferten) Medizinprodukts ist. Das trifft in den folgenden Fällen zu:
- Der Hersteller liefert das Produkt inklusive Hardware und Betriebssystem sowie JVM aus (Fall 4 in obiger Abbildung). Das ist bei physischen Medizingeräten der Fall.
- Der Hersteller liefert alles außer der Hardware aus (Fall 3). D.h. der Hersteller setzt nur eine „nackte“ Hardware voraus.
- Der Hersteller setzt nur die Hardware und das Betriebssystem voraus und liefert seine Software einschließlich JVM aus (Fall 2).
Sobald der Hersteller es dem Kunden überlässt, die Hardware und das Betriebssystem einschließlich Java Virtual Machine zu besorgen, und dem Kunden die JVM nicht mitliefert, ist diese Virtual Machine keine(!) SOUP, sondern Teil der Laufzeitumgebung (Fall 1). Daran ändert sich auch nichts, wenn der Hersteller die Anforderungen an die Laufzeitumgebung spezifiziert z.B. in Form von Hardware-Anforderungen, Mindestversion eines Betriebssystems oder JVM-Version bzw. Hersteller. Die Java Virtual Machine ist dann keine SOUP.
Lesen Sie hier mehr zum Thema Software of Unknown Provenance (SOUP).
Anforderungen an SOUPs (ggf. auch an JVM)
Die Anforderungen der IEC 62304 an SOUPs gelten auch für Java Virtual Machines. Insbesondere sollten Sie
- die Anforderungen an die JVM spezifizieren: Hier empfiehlt es sich, festzulegen, welche Funktionen der JVM besonders relevant sind, wie beispielsweise der Zugriff auf den Netzwerkstack, der Dateizugriff oder die Abstraktion der Bildschirmansteuerung. Diese Anforderungen sind relativ generisch. Stellen Sie fest, welche dieser Anforderungen besonders wichtig sind, um Risiken für Patienten und Anwender zu vermeiden. Zu den Anforderungen können auch das Verhalten bei hoher Last oder der Umgang mit vielen Threads betreffen.
- die Voraussetzungen spezifizieren, von denen die JVM ausgehen muss: Das sind insbesondere das Betriebssystem (Typ, Versionen) und die Hardware-Konfigurationen.
Schließlich müssen Sie testen, dass die Anforderungen bei den gegebenen Voraussetzungen erfüllt werden.
Typische Fehler beim Umgang mit Java Virtual Machines
Wir stoßen regelmäßig auf folgende Probleme in Audits und bei Einreichungen von Produktakten:
- Die Anforderungen an die JVM sind nicht spezifiziert.
- Die Hersteller haben die Hardware und das Betriebssystem nicht festgelegt, auf denen die Virtual Machine laufen soll.
- Die JVM erscheint nicht in der Liste der SOUPs und/oder wir in der nachgelagerten Phase nicht verfolgt.
- In der Software-Architektur wird diese Virtualisierungsschicht nicht beschreiben.
- Hersteller lassen sich von Auditoren in wenig zielführende Diskussionen verwickeln, ob der Einsatz einer JVM nicht unnötige Risiken verursachen würde.
- Die JVMs werden nicht gepatched und werden somit zum Problem für die IT-Security.
- Die Hersteller haben keinen Überblick darüber, in welchem Produkt bzw. bei welchem Kunden welche Version einer Java Virtual Machine läuft.
- Die Entwickler entwickeln und testen auf anderen Versionen als denen, die bei den Kunden im Einsatz sind.
