Asahi 7.1 maps the DMA layer under macOS
Asahi Linux 7.1 exposes Apple Silicon coprocessors, DART IOMMU boundaries, and a silent SMC firmware ABI change - the layer below every macOS EDR agent.
Asahi Linux published its 7.1 progress report in June 2026. M3 audio output works - speakers and headphone jack. Big.LITTLE task scheduling landed. m1n1, the bootloader, reached 1.6.0 and now requires Rust to build its stage 2. Yureka carried the M3 core drivers: PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad.
The OS is not the story. The reverse engineering is. Every line in that report is a map of Apple Silicon internals Apple does not document - coprocessors, firmware ABIs, and IOMMU boundaries that sit under every macOS endpoint. That is the layer where firmware bugs live and where no EDR agent can see them.
Start with the architecture, because the exposure follows from it. An M-series SoC is not one processor. It is a host CPU surrounded by coprocessors, each running its own firmware. AVD decodes video on a Cortex-M3 with fixed-function decoder units. AGX is the GPU, driven by its own ASC coprocessors. SMC handles power, thermals, and sensors. SEP is the Secure Enclave, running a separate OS on a dedicated core. ANE is the neural engine. Every one of these has DMA reach into system memory. Every one is gated by DART - Apple’s IOMMU.
DART is the whole control boundary, so understand what it does. It is a page-table-based translation unit. Each coprocessor stream carries a stream identifier and translates a device virtual address to a physical page through a DART instance. The mapping decides which physical pages a given coprocessor can touch. If a driver sets up a large persistent linear region for throughput - decoders and GPUs want big contiguous buffers - the coprocessor can address all of it. If a coprocessor is compromised and its DART mappings are coarse or reused, that coprocessor writes into host kernel memory. There is no second MMU boundary the operating system controls behind DART. That is the primitive that matters on this platform.
Apple ships all of this firmware as opaque signed blobs. No source. No documented interface. No advisory when it changes. The 7.1 report contains a clean, concrete example of what that opacity costs.
macOS 27 changed the SMC battery-management interface. The return type moved from a 32-bit integer to a single byte. The kernel driver still read the old width. It misinterpreted the value, decided the battery had failed, and triggered emergency shutdowns. Asahi corrected the driver in kernel 7.0.12 to match the new contract.
Read that as a bug class, not a battery fault. A firmware ABI changed under the operating system with no disclosure. The consumer read the declared width, not the actual width. Width mismatches at a trust boundary are the seed of memory corruption - the same defect that becomes a heap overflow when a consumer copies N bytes because the producer once declared N. Here it only crashed the machine. The mechanism is identical to ones that do not stop at a crash. And it shipped silently in a point release of macOS, which tells you the cadence: Apple mutates firmware ABIs under the OS without a changelog anyone can act on.
The video decoder is the sharper surface. AVD parses attacker-controlled input by definition - H.264 bitstreams, up to 10-bit AVC at 4K in the current driver. Malformed stream parsing is the oldest memory-safety target there is: reference frame handling, slice headers, entropy coding state. The AVD firmware runs on a Cortex-M3, a small core with full control of the decoder’s address space and no meaningful privilege separation on-die. It feeds fixed-function DMA engines. On macOS that firmware is closed. A decoder-side overflow driven by a crafted stream would execute inside a coprocessor that holds DMA. From there the escalation path is DART. Coarse mappings turn coprocessor code execution into an arbitrary write into host kernel pages. This is the DMA attack class - MITRE T1200 for the hardware-adjacent variant, firmware persistence under T1542.001. Asahi now runs custom AVD firmware behind a V4L2 driver written by sofus. That does not remove the hardware. It documents the boundary Apple hides, and it puts the DART setup in open kernel code where the mapping size is auditable instead of assumed.
m1n1 1.6.0 moves GPU initialization out of the kernel driver and into the bootloader. Boot-time code that programs the GPU coprocessors before the OS loads is pre-OS execution - T1542, and T1542.001 for the firmware layer specifically. The release also adds SPMI controller support, PCIe initialization, and UART tunneling over DebugUSB through a tool called kisd. A tunneled debug UART is a control channel. On a research machine it is a feature. As an interface, it is one more path that exists on the silicon whether or not the shipping OS exposes it. The same release lays groundwork for M4 and A18 Pro - the coprocessor topology and the DART model carry forward across the line.
SEP is the one coprocessor Asahi does not reimplement. It runs sepOS on a dedicated core, holds key material, and gates Touch ID and passcode verification. Asahi uses it as a black box for what it must and otherwise leaves it untouched. So the most security-critical coprocessor on the die stays fully opaque even under Linux. The historical class is known - bootrom-level SEP compromises on older A-series parts in the checkm8 era demonstrated what firmware-level access to a secure coprocessor yields. M-series does not inherit that specific bootrom flaw. It does inherit the model: a coprocessor whose firmware and internal state no host tool can inspect.
None of this is theoretical for Apple Silicon. PACMAN, disclosed in 2022, used speculative execution to build a pointer-authentication oracle and defeat PAC on M1 - a silicon feature, bypassed through hardware behavior, not patchable in software. GoFetch, 2024, showed the data-memory-dependent prefetcher on M-series leaks key material across what should be a constant-time boundary. Augury exposed the same prefetcher class earlier. These are architectural defects. They do not get clean patches because the flaw is in the silicon. Apple’s answer to that layer is opacity - fewer public interfaces, fewer documented internals, fewer records anyone can triage.
That last part is the operational cost. The SMC regression got no CVE. The coprocessor firmware Apple ships gets no advisory when its ABI changes. There is no CVSS vector to score because there is no published vulnerability record. The interface simply changes, and something breaks or it does not. A security program that runs on CVE feeds and vendor advisories sees none of this happen.
Telemetry makes the gap worse. macOS endpoint tooling - CrowdStrike, SentinelOne, and the Apple Endpoint Security framework they build on - instruments the kernel syscall boundary. Process exec, file events, network connections, code-signing evaluation. ESF sees a process open a file. It does not see a DART remap. It does not see AVD firmware execute. It does not see SMC ABI traffic. There is no Sysmon-equivalent for a coprocessor. Sysmon Event ID 10 gives you cross-process handle access on Windows; there is no analog for one coprocessor DMA-reading another’s memory. If an AVD or SEP firmware condition were exploited, the endpoint agent would emit nothing, because the execution never crosses the boundary the agent monitors. Defenders are blind at exactly the layer Asahi is now documenting.
There is one place a downstream stage becomes visible. A coprocessor has no network stack. Exfiltration or a callback still traverses the host NIC, and that surfaces in flow data and at the kernel networking layer the same as any other host process. So the detection opportunity is not the coprocessor stage - that stage is dark. It is the pivot, the moment coprocessor-held write primitive converts into host kernel execution and the compromise starts doing things the kernel mediates. Everything before that pivot produces no event to correlate.
The irony is direct. The open driver source is the clearest public description of these interfaces that exists anywhere. It serves defenders who want to know what runs below their agents. It serves anyone studying the same surface for other reasons. Apple’s opacity did not remove the attack surface. It removed the documentation and the telemetry and left the surface intact.
For operators running Apple Silicon fleets under real obligations - SOCI-covered infrastructure in Australia, anything where endpoint monitoring is a control you attest to under the Privacy Act - the gap is concrete, not abstract. EDR coverage stops at the kernel. Coprocessor firmware, DART state, SEP internals: none of it enters the log pipeline, and none of it generates a signal to alert on. That is not a detection-tuning problem. There is no telemetry to tune. If a coprocessor-level condition is ever suspected on a production endpoint, it goes to the platform security team and the vendor, not to SOC triage, because the SOC has nothing to triage it with.
The patch boundary is narrow. Asahi kernel 7.0.12 fixed the SMC width regression on the Linux side. Everything else stands. The coprocessors are still black boxes under macOS. DART still mediates DMA through mappings no defender can inspect. The firmware still updates without advisories. PACMAN and GoFetch still describe silicon behavior no point release removes. Reverse engineering is not the exposure. The exposure is a platform that runs a dozen firmware processors below a monitoring layer that cannot see any of them - and a vendor that treats not documenting the bugs as equivalent to not having them.
See also: NordVPN for tunneled traffic when operating outside controlled networks.
#ad Contains an affiliate link.
Keep Reading
MITRE ATT&CKThis isn't a bug. It's the default.
Codex writes unbounded session logs to local SSDs. Mapped correctly to MITRE T1499, not T1071 - a disk-exhaustion DoS primitive EDR baselines miss.
vulnerability researchSixty-three days to patch a forked parser
Technical breakdown of the FrontierOS RCE: a forked XML parser, an unpatched two-year-old CVE, and the fork-tracking failure that shipped it.
CVE-2025-3891axios CVE-2025-3891: What the Advisories Don't Say About Immutable Images
CVE-2025-3891 in axios allows prototype pollution leading to RCE. This post reveals why deployed container images remain at risk even after patching, due to missing artifact provenance and immutable verification.
Stay in the loop
New writing delivered when it's ready. No schedule, no spam.