Raghu Bharadwaj

Posted on Sep 12 Originally published at techveda.live

A Certified Hypervisor Does Not Cover the Linux Guest

#linux #automotive #embedded #safety

TÜV Rheinland's public certificate register lists QNX Hypervisor for Safety under number 968/FSP 1976.08/26, assessed against ISO 26262-2:2018, ISO 26262-6:2018 and ISO 26262-8:2018 and usable as a Safety Element out of Context to realise safety goals up to ASIL D. The type designation on that entry is the hypervisor. It is not the guests the hypervisor hosts, and the standards list does not include ISO 26262-9:2018, which is the part covering criteria for coexistence of elements and analysis of dependent failures. A Linux guest placed beside a certified hypervisor inherits a partitioning mechanism, not a safety argument.

Engineers consolidating an instrument cluster, an infotainment surface and a body-control function onto one system-on-chip are usually told the same thing by the platform team: the hypervisor is certified, so the Linux side is isolated and stays outside the safety argument. The first half of that sentence can be checked in a public register in about two minutes. The second half is not written anywhere in the certificate. This post reads the actual register entry for a certified hypervisor, states what its scope covers, and works through what a Linux guest sitting next to it still owes the person who has to build the item.

What the public register actually records

TÜV Rheinland publishes its functional-safety product certificates in a searchable database at fs-products.tuvasi.com. Read on 12 September 2026, that database showed 7,042 records with a dateline of 09-2026. Two entries in it matter to anyone relying on a certified hypervisor, and QNX links to both from its own certifications page.

The first is certificate 968/FSP 1976.08/26. The certificate holder and manufacturer is BlackBerry Limited. The product category is Software with the sub-category Others, the subject is recorded as "Hypervisor", and the type designation is "QNX Hypervisor for Safety (QHS)", with released and approved versions deferred to a separate revision list. The codes and standards are given as six documents: IEC 61508-1:2010, IEC 61508-3:2010, ISO 26262-2:2018, ISO 26262-6:2018, ISO 26262-8:2018, and IEC 62304:2006 with Amendment 1:2015, the last one explicitly excluding clauses 4.2 and 4.4. The scope states that the product complies with the requirements of those standards at ASIL D according to ISO 26262, SC 3 according to IEC 61508 and Class C according to IEC 62304, and that it can be used as a Safety Element out of Context in items in order to realise safety goals up to ASIL D.

The second is certificate 968/FSP 2999.02/26, for QNX OS for Safety, categorised as Software and subject "Real Time Operating System (RTOS)". It names the same six standards and reaches the same integrity levels. It also does something more interesting, which is to scope the product internally. The register entry states that the provided tool chain, classified as TCL3 and T3, complies with the applicable requirements for supporting tools according to ISO 26262-8 and off-line support tools according to IEC 61508-3. It then splits the C++ library in two: the runtime components can be used to realise safety goals up to ASIL D, while the C++ library headers and templates can be used only up to ASIL B according to ISO 26262 and SIL 1 according to IEC 61508.

That split deserves attention, because it is the clearest available demonstration that a certificate is a statement about parts of a product rather than about a product. Two pieces of the same shipped library, from the same vendor, under one certificate number, carry different integrity ceilings. An application that instantiates a template from that library inside an ASIL D function cannot lean on the certificate for that instantiation. The register does not record the assessor's reasoning, so this post does not offer one. What it does record is the boundary, and with a certified hypervisor as with a certified library, the boundary is the thing an integrator has to design around.

Both entries carry the same two administrative facts. Under "Valid Until" each says "no expiry date". Under "Specific Provisions" each says that the operating conditions and functional characteristics specified in the Safety Manual and accompanying documents must be observed, and that the current versions of software are specified in the currently valid revision list, released by the manufacturer in cooperation with the certification body. The hypervisor entry's revision list is dated 12 March 2026; the OS entry's is dated 13 March 2026.

The strongest case for putting the critical function on the microkernel

Before any Linux-side response, it is worth stating plainly why a functional-safety engineer picks a certified microkernel, and a certified hypervisor above it, for the domain whose failure can injure a person, because the reasons are good ones and they are not commercial.

The first is that the evidence already exists and has a reference number. An integrator can put "968/FSP 1976.08/26" into a safety plan and an assessor can look it up. That is a different situation from having to construct a qualification argument for a component from scratch, and the difference shows up in schedule and in cost.

The second is that Safety Element out of Context is a real division of labour, not a label. The supplier has performed development activities against ISO 26262-2:2018 and ISO 26262-6:2018 and hands over a Safety Manual containing the assumptions it made about the context it would be used in. The integrator's remaining job is to check those assumptions hold in the actual item and to document where they do not. That is bounded work that can be planned and staffed. Building the equivalent evidence for an uncertified component is not bounded in the same way.

The third is the tool chain. ISO 26262-8:2018 lists confidence in the use of software tools among its subjects, and qualifying a compiler is a substantial exercise on its own. The QNX OS for Safety register entry places the supplied tool chain inside the assessed scope at TCL3 and T3. Anyone who has priced a compiler qualification separately will understand what that is worth.

The fourth is architectural. A microkernel moves device drivers, file systems and protocol stacks out of the privileged kernel and runs them as ordinary user-space processes. The code executing at the highest privilege level is therefore much smaller than in a monolithic kernel, and a fault in a driver is a fault in a restartable process rather than a fault inside the trusted computing base. The QNX Hypervisor for Safety 8.0 solution brief describes exactly this arrangement, with the QNX scheduler managing guest execution and separate process and memory managers enforcing isolation and controlled shared memory.

The fifth is timing. The same brief states that the hypervisor supports Virtualization Host Extensions on ARMv8 AArch64 processors, which lets it run at Exception Level 2, the privilege level the hardware provides for virtualisation, and that this reduces the cost of switching between guests and the hypervisor. It also states that both Symmetrical Multiprocessing and Bound Multiprocessing are supported, so virtual CPUs can be pinned to specific physical cores. Pinning is not a performance optimisation in this context; it is how an integrator removes a scheduling variable from the timing argument.

The sixth is accountability. One company's name sits on the certified hypervisor's register entry, and the revision list is released by that company in cooperation with the certification body. When a defect is found there is one party responsible for the corrective action and one register entry that gains a new revision. An OEM's supplier-quality process is built around exactly that shape.

An engineer who chooses this arrangement for a function with a high integrity target is not dressing up a commercial preference as an engineering one. In choosing a certified hypervisor they are choosing the option where the evidence already exists, where the residual work is bounded, and where somebody else is contractually answerable for the part they did not write.

Where a certified hypervisor stops

The register entry is precise about its subject, and reading it closely tells you where the certified hypervisor's scope ends.

The type designation is "QNX Hypervisor for Safety (QHS)". A guest operating system is not part of that designation. The product's own solution brief states that it enables multiple guest operating systems including Android, Linux and QNX to run on a single system-on-chip. Running a guest is what a certified hypervisor does; certifying that guest is not.

The Specific Provisions field makes the Safety Manual binding. Any claim an integrator makes on the strength of a certified hypervisor is conditional on the operating conditions and functional characteristics that manual states. If the manual assumes a particular configuration and the item ships a different one, the certificate has not been invalidated so much as never applied.

The absence of an expiry date is easy to misread. It does not mean the certificate covers whatever version is current. It means the version coverage lives in the revision list instead, and that list carries a date — 12 March 2026 for the hypervisor entry when this post was written. Moving to a hypervisor build that is not on the current list is a change-impact question, not a free upgrade.

The most consequential omission is in the codes and standards list, and it is an omission by structure rather than by oversight. The list names parts 2, 6 and 8 of ISO 26262:2018. It does not name part 9. ISO 26262-9:2018, "Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses", is Edition 2, published on 17 December 2018, 29 pages, and its ISO catalogue abstract lists its subject matter as requirements decomposition with respect to ASIL tailoring, criteria for coexistence of elements, analysis of dependent failures, and safety analyses. Those are the analyses that decide whether elements of different integrity levels may sit together and whether a single cause can take out more than one of them. They are performed on the item. A product certificate for a hypervisor cannot contain them, because the elements that have to coexist are not known until an integrator picks them. The coexistence question is therefore not answered by buying a certified hypervisor; it is opened by it.

One further scope limit is recorded by the vendor rather than the assessor. The QNX Hypervisor for Safety 8.0 solution brief carries a certification-scope table which marks ISO/SAE 21434, the road-vehicle cybersecurity engineering standard, as complete for QNX OS for Safety and "In Progress" for QNX Hypervisor for Safety. Functional safety and cybersecurity are separate assessments with separate scopes, and a product can hold one without the other.

Three ways a device reaches a guest, and what each costs the argument

The partitioning a certified hypervisor performs becomes concrete at the device boundary. The QNX Hypervisor for Safety 8.0 solution brief states that each virtual machine is configured like a physical board, with memory and devices explicitly assigned to either the guest or the hypervisor, and that a device can be configured in one of three ways.

Configuration	What it means	What it costs the interference argument
Emulated	The hypervisor fully emulates the device, so the guest needs no driver change.	Every device access traps into the host, which costs throughput and adds latency. The emulation code itself sits inside the host's scope and has to be treated accordingly.
Para-virtualised, VirtIO compliant	The guest runs a virtual driver that talks to the host through a standardised interface.	Far fewer traps, and the guest driver is portable because VirtIO is standardised and already in the Linux kernel. The cost is a shared-memory channel between domains, which is a coupling path the analysis has to account for.
Physical pass-through	The guest accesses the physical device directly, at native performance.	The device becomes a bus master under the guest's control. Stage-2 address translation constrains what the guest's CPUs can reach; it does not constrain what a device they program can reach.

That last row is where most of the real engineering sits, and it is the reason the solution brief singles out one component by name. QNX Hypervisor for Safety includes an SMMU manager service, smmuman, which works with the hardware System Memory Management Units to confine Direct Memory Access devices so that DMA-initiated transfers cannot reach memory beyond approved regions. Without a correctly configured SMMU behind a passed-through device, a buggy or compromised Linux guest can program that device to write anywhere in physical memory, including into the safety domain, and no amount of CPU-side partitioning will stop it. The SMMU configuration is therefore not a performance detail. It is load-bearing in the freedom-from-interference argument, and it is configuration the integrator sets and must verify rather than something a certified hypervisor supplies ready-made.

Interference the partition does not remove

Address-space isolation answers one question: which memory can this software name. It does not answer the other one: which resources do these domains share whether they name them or not. On a consolidated system-on-chip, the shared resources are substantial and they all sit below the certified hypervisor.

Both domains draw from the same memory controllers. A Linux guest running a display compositor, a camera pipeline or a container build can lengthen the safety domain's memory access times through queueing at the controller without ever issuing an address the partition would refuse. The same applies to the last-level cache, where pressure from one domain changes the execution-time distribution of the other, and to the on-chip interconnect, where arbitration is shared. Thermal behaviour couples them too: sustained load in one domain raises die temperature and can trigger frequency reduction that both domains experience. Where a GPU or a video engine is shared between a cluster surface and an infotainment surface, the coupling is direct.

Two consequences follow for anyone building the timing evidence. The first is that latency measurements taken with the Linux guest idle are not evidence about the shipped system; the measurement has to be made with the guest under its worst realistic load, and that load has to be described in the evidence. The second is that these coupling paths are properties of the silicon and the workload rather than of the hypervisor, which is precisely why the analysis of dependent failures named in the ISO 26262-9:2018 abstract is item-level work that no supplier can have done in advance.

None of this is a criticism of the QNX product. It applies identically when both domains run QNX. A certified hypervisor decides what software is permitted to name; the silicon decides what the domains physically share. Those are different problems and only the first one has a certificate.

What changed between December 2019 and March 2026

On 9 December 2019, BlackBerry announced that QNX Hypervisor 2.0 for Safety had been recognised as ISO 26262 ASIL D compliant by TÜV Rheinland, describing it as the world's first ASIL D safety-certified commercial hypervisor. The announcement named two standards: ISO 26262 at ASIL D and IEC 61508 at SIL 3. Thomas Steffens of TÜV Rheinland Industrie Service GmbH was quoted in it.

The register entry that exists today is a considerably more detailed object. Certificate 968/FSP 1976.08/26 carries a revision index of .08 and a 2026 registration year. It names six standard documents with their edition years rather than two standard families. It states which IEC 62304 clauses are outside the assessed scope, and separately excludes from the certification the risk-management process that IEC 62304 requires. It attaches a dated revision list for covered software versions. And the product it describes is QNX Hypervisor for Safety 8.0, built on QNX OS for Safety and on QNX Software Development Platform 8.0, according to the product page published on 10 March 2026.

The useful reading of that change is not that the product got better, which the register does not say. It is that a certificate is a maintained object rather than an award. The revision index advances, the covered-version list is reissued with a new date, and exclusions are stated explicitly. An integrator citing a certified hypervisor on the strength of the 2019 headline would be carrying a claim that is now seven years old, would have no idea which software versions are actually covered, and would miss the excluded clauses entirely. The lesson is not specific to this vendor. Before relying on any certified hypervisor, read the register entry rather than the announcement.

What the Linux guest is actually for

The honest answer for the domain with the highest integrity target is that Linux is not the right tool for it today, and the register is the reason. There is no equivalent entry for a Linux kernel at ASIL D. The assessed Linux platform that does exist sits two integrity levels lower: Red Hat announced on 20 May 2025 that Red Hat In-Vehicle Operating System had achieved functional safety certification as a Safety Element out of Context against ISO 26262 Edition 2, 2018, at Level ASIL-B, with exida as the assessor, and stated that customers receive a Safety Guidance document including Assumptions of Use. That is the same shape of deliverable as the QNX Safety Manual, at a different level, from a different assessor. If you want the detail of what a Linux certificate does and does not bound, we covered that separately in what a Linux safety certification actually covers.

What the Linux guest is for is the part of the vehicle that changes. Graphics and display stacks, connectivity, media, camera and sensor pipelines through V4L2, container runtimes, the application layer and the update path. The reason to put that next to a safety domain on one chip is not that it has become safe. It is that the bill of materials no longer supports a separate electronic control unit for it, and that the two halves have incompatible release rhythms. The infotainment surface wants a new build every few weeks. The certified domain wants to move as rarely as possible, because every move reopens a change-impact question against a dated revision list.

That lifecycle separation is the actual commercial driver behind consolidation, and it is what a partition with a documented interference argument buys. It is not isolation for its own sake. What a certified hypervisor is bought for is the ability to ship the fast-moving half without reassessing the slow-moving one.

The open-source side of the industry is converging on the same shape independently. Automotive Grade Linux announced its SoDeV reference platform on 5 December 2025, combining the AGL Unified Code Base with Linux containers, the Unified HMI framework contributed by Panasonic Automotive Systems, VirtIO, the Xen type 1 hypervisor, the Yocto Project and the Zephyr RTOS, with AGL stating that it is collaborating with the ELISA Project to support future ASIL functional-safety applications within SoDeV. The initiative is led by Panasonic Automotive Systems, Honda and the AGL SDV Expert Group, with contributions from Toyota, Mazda, AISIN and Renesas, and availability was planned for early 2026. General-purpose Linux beside a small RTOS under a type 1 hypervisor is the same architectural answer, reached with an open hypervisor that carries no product certificate at that layer. Whether a certified hypervisor or an open one is the right choice depends entirely on what the integrator has to prove and to whom.

Key takeaways

TÜV Rheinland certificate 968/FSP 1976.08/26 covers QNX Hypervisor for Safety as a Safety Element out of Context up to ASIL D, against ISO 26262-2, -6 and -8:2018. The type designation is the hypervisor; guest operating systems are not in it.
ISO 26262-9:2018, whose abstract names criteria for coexistence of elements and analysis of dependent failures, is absent from that standards list. Those analyses are item-level work that no component supplier can complete in advance.
A certificate with no expiry date still limits its coverage, through a dated revision list of software versions — 12 March 2026 for the hypervisor entry, 13 March 2026 for the QNX OS for Safety entry.
Certificate 968/FSP 2999.02/26 scopes one library in two pieces: C++ runtime components up to ASIL D, headers and templates up to ASIL B. Certificates describe parts of products, not products.
Stage-2 translation controls what software can name. Memory bandwidth, last-level cache, interconnect arbitration, thermal behaviour and shared accelerators are not controlled by it, and timing evidence measured with the Linux guest idle is not evidence about the shipped system.
For a passed-through device, the SMMU configuration is part of the freedom-from-interference argument, not a performance setting. It is configuration the integrator owns, not something a certified hypervisor settles.

Frequently asked questions

Does a certified hypervisor make the Linux guest safety-certified?
No. The type designation on certificate 968/FSP 1976.08/26 is QNX Hypervisor for Safety. Guest operating systems are not part of the certified product, and the certificate makes no statement about them.

Why does it matter that ISO 26262-9:2018 is not in the certificate's standards list?
Part 9 covers criteria for coexistence of elements and analysis of dependent failures, according to its ISO catalogue abstract. Those analyses depend on which elements are actually combined in the item, so they can only be performed by the integrator, not by the component supplier in advance.

The certificate says "no expiry date". Does that mean any version is covered?
No. The covered software versions are listed in a separate revision list that the manufacturer releases in cooperation with the certification body. The hypervisor entry's list is dated 12 March 2026, so moving to a build outside it is a change-impact question.

If a certified hypervisor partitions memory, why does the Linux guest's workload still affect timing in the safety domain?
Because the partition controls address spaces, not shared hardware. Both domains use the same memory controllers, caches, interconnect and thermal budget, so load in one can lengthen execution times in the other without any address-space violation occurring.

Is there a Linux equivalent of the ASIL D certificate held by QNX OS for Safety?
Not at that level in the public record checked for this post. The assessed Linux platform that exists is Red Hat In-Vehicle Operating System, certified as a Safety Element out of Context against ISO 26262 Edition 2, 2018 at Level ASIL-B, with exida as the assessor.

DEV Community