Loading story…
The seL4 microkernel has gained formal verification support for the AArch64 architecture, extending its mathematically proven correctness and security properties to 64-bit ARM platforms. The project said the work adapts seL4’s verification framework to another major processor family used in security-sensitive and safety-critical systems, where strong isolation and reliability are required.
seL4 is widely positioned as a high-assurance microkernel for embedded and specialized environments, and the new milestone expands coverage beyond earlier formally verified support for 32-bit ARM, x86_64, and RISC-V. By proving implementation behavior against specified properties, the verification effort is intended to reduce the risk of software flaws in deployments that depend on trusted operating-system foundations.
See the reporting duties and controls this puts on the clock.
2 events from the most recent confirmed update back to the earliest known activity.
The seL4 project announced that its security proofs are now complete on the AArch64 architecture. This marks a new milestone beyond earlier reports that formal verification had been extended to support AArch64.
The seL4 microkernel's formal verification work was extended to support the AArch64 architecture, expanding verified platform coverage to 64-bit ARM systems. The reports describe this as a new milestone for seL4's use in high-assurance and security-sensitive environments.
See what this changes for your reporting obligations and which controls it puts on the clock.
3 references tracked. Mallory keeps watching after this page renders.
opennet.ru
Open sourceopennet.me
Open sourcelists.sel4.systems
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers from CISPA Helmholtz Center for Information Security and KU Leuven reported that several commercial out-of-order RISC-V processors are vulnerable to major Spectre speculative-execution attacks, challenging assumptions that the architecture was largely resistant to this class of flaws. The affected chips include **SiFive P550** and **T-Head Xuantie C910/C920**, which were found susceptible to `Spectre-PHT`, `Spectre-BTB`, `Spectre-RSB`, and `Spectre-STL`, while tested in-order processors such as **SiFive U74** and **Xuantie C906/C908** did not appear vulnerable. The researchers demonstrated proof-of-concept exploits with up to **100% recall** and more than **97% precision**, including leakage of arbitrary Linux kernel memory from the **Xuantie C910** at **338 bytes per second**. They said mitigations developed for x86 and ARM do not transfer cleanly to RISC-V because of limited hardware introspection and ecosystem diversity; following responsible disclosure in December, three Linux patches were merged upstream and both **SiFive** and **T-Head** have taken or committed to mitigation steps.
Aug 13, 2026
The Linux `7.2` merge window has introduced several security-focused changes, including support for updating Intel **Trusted Domain Extensions** (TDX) modules on running systems, a step aimed at improving maintainability for confidential-computing deployments without requiring downtime. The kernel also adds arm64 hardening to remove data regions from the linear map, strengthens `openat2()` with `OPENAT2_REGULAR` and `EFTYPE` handling, and extends `fs-verity` support in `iomap` alongside a new `dm-inlinecrypt` device-mapper target. Additional protections target exploit resistance and attack-surface reduction across the kernel. The slab allocator now supports Clang allocation tokens to make cross-object memory corruption harder to exploit, while PowerPC’s hardware-optimized `MD5` implementation is being removed and `AF_ALG` is being deprecated after multiple recent security issues, including removal of its hardware-accelerator support. The update also includes broader networking and BPF changes, but the most notable theme is a sustained push to harden core kernel subsystems and reduce exposure from legacy or problematic components.
Aug 17, 2026
Arm disclosed **CVE-2025-10263**, a critical flaw in many Arm CPU cores that can let memory accesses complete incorrectly during permission changes, creating a path for writes to resources owned by a higher exception level. The issue stems from a timing condition in TLB invalidation handling where completion of a `TLBI` is not guaranteed to mean all affected memory accesses have completed, leaving stale translations usable across privilege boundaries. Affected processors include multiple **Arm Neoverse** and **Cortex** cores as well as **NVIDIA Olympus**, and the flaw has implications for Stage 1, Stage 2, and **GPT** protections used for memory isolation and virtualization. Vendors and projects released coordinated advisories and patches after disclosure. **Linux** posted kernel fixes implementing Arm's software workaround, which adds an extra `TLBI` and `DSB` in certain invalidation paths, while **NVIDIA** issued a related mitigation for Olympus-based Vera CPUs. **Xen** published **XSA-493 v2**, warning that on multi-core Arm systems a malicious guest could potentially keep writing after Stage 2 permissions were changed, enabling hypervisor-level privilege escalation; patches were released for `xen-unstable` and supported stable branches from **Xen 4.17** through **4.21**. **FreeBSD** also issued an `arm64` security advisory covering the hardware issue.
Jun 29, 2026