Skip to content
Miatafy

Mazda Connect Service Architecture

Overview

Section titled “Overview”

The CMU runs roughly 105-117 services under a central service manager. They launch in staged waves at boot, with dependency gates between stages: the manager starts every service in a stage before moving to the next, so a prerequisite is always up before anything that needs it.

That gating is why boot is slow. The dependency chain pulls in services for hardware the car was never built with, and an active service can’t start until the defunct ones ahead of it in the chain finish initializing.

Source basis: service categories and general architecture are cross-checked against silverchris’s D-Bus interface notes and local firmware analysis. Counts vary by firmware revision and trim.

Service Categories

Section titled “Service Categories”
CategoryPurpose
Audio & MediaUSB audio, Bluetooth audio, satellite radio, streaming services
NavigationMap rendering, route calculation, GPS positioning
ConnectivityBluetooth pairing and profiles, Wi-Fi, telematics
UI & DisplayOpera browser (HTML/JS/CSS rendering), Wayland compositor, touchscreen input
Vehicle IntegrationVIP MCU bridge (read-only CAN bus telemetry), instrument cluster communication
VoiceSpeech recognition, text-to-speech, voice command processing
SystemUpdate services, device management, logging, diagnostics

How Services Are Loaded

Section titled “How Services Are Loaded”

Each service is an individual process started by the service manager. Per-service configuration attributes control whether it auto-starts, how many times it retries on failure, and which other services it depends on.

Stages run in sequence; services within a stage can come up in parallel, but the stage boundary is a barrier. The practical consequence: boot time is set by the slowest path through the dependency graph, not by the count of services, and a single stalled service in an early stage holds back everything behind it.

Resource Impact

Section titled “Resource Impact”

A large share of services consume RAM for features that are no longer functional on most vehicles. The defunct streaming back ends are the clearest example — the third-party services they talked to were shut down years ago, but the clients still load.

  • Legacy streaming clients (Aha, Pandora, Stitcher, Slacker) consume roughly 39 MB combined
  • Satellite radio services consume roughly 47 MB on vehicles without SiriusXM hardware
  • Telematics services consume roughly 38 MB on vehicles without connected-services hardware

See Runtime Analysis for the live process and memory measurements these figures come from.

Security Model

Section titled “Security Model”

Services run with limited privilege separation. The analyzed rootfs ships no SELinux, AppArmor, or comparable mandatory access control. Most services restart on failure; a handful of critical ones trigger a full system reboot when they can’t recover, which is why a single misbehaving service can manifest as a reboot loop rather than a degraded feature.

For what this exposes to an attacker, see Attack Surface.

Section titled “Related Pages”