M1RACLES: Apple M1 Chip Covert Channel Bypasses OS Isolation

A design flaw in the Apple Silicon "M1" chip allows any two applications running under an OS to covertly exchange data between them, without using memory, sockets, files, or any other normal operating system features. This works between processes running as different users and under different privilege levels, creating a covert channel for surreptitious data exchange.
The vulnerability is baked into Apple Silicon chips and cannot be fixed without a new silicon revision.

The M1RACLES vulnerability (CVE-2021-30747) exploits the s3_5_c15_c10_1 ARM system register, which is accessible from EL0 (user space) on Apple M1 chips. Two processes can use this register as a 2-bit communication channel, exchanging data at megabits-per-second rates without any OS-mediated IPC mechanism. This means the covert channel is invisible to all kernel-level security monitoring, sandboxing, and access control. The practical threat model centers on malware exfiltration: a sandboxed application (such as a browser tab or a containerized process) could leak sensitive data to a co-resident unprivileged process that has network access. Because the flaw exists in silicon, no software patch can eliminate it -- only a hardware revision can remove the accessible register. This vulnerability underscores that custom silicon introduces custom attack surfaces, and Apple's ARM implementation is not immune to the same class of side-channel issues that affected Intel (Meltdown, Spectre) and AMD (Zenbleed).

MIPS Technologies Abandons MIPS ISA, Pivots to RISC-V

What a long, strange trip it has been. MIPS Technologies no longer designs MIPS processors. Instead, it has joined the RISC-V camp, abandoning its eponymous architecture for one with strong historical and technical ties. The move apparently signals the end of the road for MIPS as a CPU family and a further reduction in the variety of processor architectures available. It is the final arc of an architecture.

MIPS pivoting to RISC-V validates the open ISA model's competitive viability against proprietary architectures. The critical advantage of RISC-V over ARM is economic: RISC-V is royalty-free and license-free, meaning chip designers pay zero per-unit fees and face no contractual restrictions on extensions. ARM charges per-core licensing fees that range from $0.01 to $2+ per chip depending on the core design, which adds up to billions in aggregate industry costs. For MIPS Technologies specifically, maintaining a proprietary ISA with a shrinking market share became unsustainable against both ARM's ecosystem dominance and RISC-V's zero-cost entry. The RISC-V ecosystem now has production-grade cores from SiFive, Alibaba (Xuantie), and others, with Linux kernel support maturing rapidly. The long-term implication is a potential three-way architecture split: x86 for legacy enterprise, ARM for mobile and Apple Silicon, and RISC-V for IoT, embedded, and cost-sensitive datacenter applications.

Google FLoC Replaces Third-Party Cookies with Cohort-Based Targeting

The choice of what ads to show on a web page may typically be based on three broad categories of information: (1) First-party and contextual information (e.g., "put this ad on web pages about motorcycles"); (2) general information about the interests of the person who is going to see the ad (e.g., "show this ad to Classical Music Lovers"); and (3) specific previous actions the person has taken (e.g., "offer a discount on some shoes that you left in a shopping cart"). This document addresses category (2), ads targeting based on someone's general interests. For personalized advertising in category (3), please check out the TURTLEDOVE proposal. In today's web, people's interests are typically inferred based on observing what sites or pages they visit, which relies on tracking techniques like third-party cookies or less-transparent mechanisms like device fingerprinting. It would be better for privacy if interest-based advertising could be accomplished without needing to collect a particular individual's browsing history. We plan to explore ways in which a browser can group together people with similar browsing habits, so that ad tech companies can observe the habits of large groups instead of the activity of individuals. Ad targeting could then be partly based on what group the person falls into. Browsers would need a way to form clusters that are both useful and private: Useful by collecting people with similar enough interests and producing labels suitable for machine learning, and private by forming large clusters that don't reveal information that's too personal, when the clusters are created, or when they are used. A FLoC cohort is a short name that is shared by a large number (thousands) of people, derived by the browser from its user's browsing history. The browser updates the cohort over time as its user traverses the web. The value is made available to websites via a new JavaScript API: The browser uses machine learning algorithms to develop a cohort based on the sites that an individual visits. The algorithms might be based on the URLs of the visited sites, on the content of those pages, or other factors. The central idea is that these input features to the algorithm, including the web history, are kept local on the browser and are not uploaded elsewhere — the browser only exposes the generated cohort. The browser ensures that cohorts are well distributed, so that each represents thousands of people. The browser may further leverage other anonymization methods, such as differential privacy. The number of cohorts should be small, to reinforce that they cannot carry detailed information — short cohort names ("43A7") can help make that clear.

FLoC (Federated Learning of Cohorts) represents Google's attempt to preserve ad targeting effectiveness while eliminating cross-site tracking via third-party cookies. The technical mechanism groups users into cohorts of thousands based on locally-computed browsing similarity, then exposes only the cohort ID (e.g., "43A7") via a JavaScript API. The privacy improvement over third-party cookies is real but limited: researchers demonstrated that cohort IDs, when combined with other fingerprinting signals (screen resolution, installed fonts, WebGL renderer), can still narrow identification to small groups. The broader concern is architectural -- FLoC consolidates interest classification inside the browser itself, which happens to be Chrome with 65%+ market share, effectively making Google the gatekeeper of the replacement system for the tracking mechanism it is deprecating. Mozilla, Brave, and the EFF all declined to implement FLoC, and Google ultimately replaced it with the Topics API in 2022, which uses a more coarse-grained taxonomy of roughly 350 interest categories.

JEP 382: Java 2D Rendering Pipeline Migrates to macOS Metal API

Motivation Two major factors motivate the introduction of a new Metal-based rendering pipeline on macOS: Apple deprecated the OpenGL rendering library in macOS 10.14, in September 2018. Java 2D on macOS is completely reliant on OpenGL for its internal rendering pipeline, so a new pipeline implementation is needed. Apple claims that the Metal framework, their replacement for OpenGL, has superior performance. For the Java 2D API, this is generally the case with some exceptions. Description Most graphical Java applications are written using the Swing UI toolkit, which renders via the Java 2D API. Internally, Java 2D can use software rendering plus a blit to the screen or it can use a platform-specific API, such as X11/Xrender on Linux, Direct3D on Windows, or OpenGL on macOS. These platform-specific APIs typically offer much better performance than software rendering, and generally off-load the CPU. Metal is the new macOS platform API for such rendering, replacing the deprecated OpenGL API. (The name has nothing to do with the Swing "Metal" Look and Feel; that is just a coincidence.)

JEP 382 is a necessary survival measure for Java desktop applications on macOS. Since Apple deprecated OpenGL in macOS 10.14 (2018) and has been progressively degrading its OpenGL implementation (frozen at version 4.1 since 2011), every Swing and JavaFX application on macOS was running on an effectively abandoned rendering backend. The Metal migration ensures that Java 2D rendering continues to receive driver optimizations and GPU acceleration on Apple hardware. This also demonstrates a notable advantage of Java's platform abstraction: a Swing application written in 2005 continues to render correctly in 2021 on completely different GPU hardware and APIs, with zero application code changes. By contrast, web UI frameworks from the same era (Prototype, MooTools, early jQuery) are long obsolete. The Metal pipeline does not affect Linux (X11/Xrender) or Windows (Direct3D) rendering paths, so this is a macOS-specific improvement that maintains Java's cross-platform contract.

KDE Plasma 5.21 Delivers Major Wayland Compositor Improvements

KWin and Wayland KDE is pushing to have first class support for Wayland, and Plasma 5.21 makes massive progress towards reaching that goal. We have extensively refactored the compositing code in KWin and the changes should reduce latency throughout all compositing operations. We have also added a control in the compositing settings so you can choose whether you prefer lower latency or smoother animations. In addition, we have also added support for mixed-refresh-rate display setups on Wayland, e.g. you can have one screen refreshing at 144Hz and another at 60Hz, which is ideal for improving work-stations with multiple monitors. Preliminary support for multiple GPUs was also added on Wayland. The virtual keyboard in Wayland has been improved and now supports GTK applications using the text-input-v3 protocol. The support for graphical tablets has also been improved and now includes all the controls that were missing in the previous version, such as pad ring and pad buttons. Apart from the numerous improvements in stability, there are quite a few Plasma components that are getting much better support in Wayland. KRunner, for example, is now able to list all open windows in Wayland, a new component in the panel's system tray informs you of the keyboard layout, and we now support features required for GTK 4, so all GTK 4 applications will now work.

Plasma 5.21's Wayland improvements address three of the most cited blockers for Wayland adoption on KDE. First, mixed-refresh-rate monitor support (e.g., 144Hz gaming display plus 60Hz productivity panel) was previously impossible because KWin composited all outputs at a single rate, causing either stuttering on the fast display or wasted GPU cycles on the slow one. The new per-output rendering loop matches each monitor's native refresh rate independently. Second, multi-GPU support enables hybrid GPU laptops (Intel iGPU plus NVIDIA/AMD dGPU) to use Wayland without falling back to X11, which was a hard requirement for many developer and creative workstations. Third, GTK 4 compatibility via text-input-v3 ensures that the growing number of GNOME applications ported to GTK 4 render and accept input correctly under KWin's Wayland compositor, preventing a toolkit fragmentation problem where switching desktop environments meant losing application compatibility.

AlmaLinux and Rocky Linux Emerge as CentOS Stream Replacements

Rocky Linux is a community enterprise operating system designed to be 100% bug-for-bug compatible with America's top enterprise Linux distribution now that its downstream partner has shifted direction. It is under intensive development by the community. Rocky Linux is led by Gregory Kurtzer, founder of the CentOS project. There is no ETA for a release. Contributors are asked to reach out using the communication options offered on this site.

vs

In December 2020, the community lost one of its most important resources. Red Hat announced that CentOS would no longer be issued as a stable release, instead replaced by the continuously updated CentOS Stream. At CloudLinux we quickly realized the vast implications of Red Hat's announcement, so we stepped in to commit to a CentOS replacement: a 1:1 binary compatible fork of RHEL® that is free to use, and open source. We gave it the code name Project Lenix. Now, we are announcing the results of Project Lenix: AlmaLinux. Due to be released in Q1 2021, the new Linux distribution enables CentOS users to easily switch to a CentOS replacement that enjoys ongoing support. Switching requires minimal effort: because AlmaLinux is a binary compatible fork of RHEL, the base for CentOS, switching from CentOS to AlmaLinux is extremely simple.

Red Hat's decision to convert CentOS from a downstream RHEL rebuild (receiving packages after RHEL release and testing) into an upstream rolling-release distribution (CentOS Stream, receiving packages before RHEL) fundamentally changed the enterprise Linux landscape. The practical impact is that CentOS Stream now serves as a testing ground for future RHEL releases, making it unsuitable for production environments that require the stability guarantees of a fixed-release distribution. AlmaLinux (backed by CloudLinux, a company with a decade of RHEL-compatible kernel development) and Rocky Linux (led by CentOS founder Gregory Kurtzer) both offer 1:1 binary-compatible RHEL rebuilds. The key differentiator between them is governance: AlmaLinux is backed by a commercial entity with existing enterprise Linux revenue, providing financial sustainability, while Rocky Linux adopted a community foundation model. For organizations migrating from CentOS 8, both distributions provide in-place migration scripts that swap repository configurations without reinstallation.

Qt 5.15 LTS Patches Restricted to Commercial Licensees Only

As part of their fundamental shift to restrict Qt LTS point releases to commercial customers, The Qt Company is closing the Qt 5.15 branch to the public tomorrow with future Qt 5.15 LTS point releases to be restricted to paying licensees. The notice was sent out today that beginning tomorrow (5 January) will start the commercial-only LTS phase of Qt 5.15. The existing Qt 5.15 branches will be publicly visible but will not see any new patches. The public branches are closed to new commits with the exception of Qt WebEngine and the deprecated Qt Script due to third-party LGPL dependencies. Only active, commercial license holders will be able to access the private repository that will have the code that comprises the future Qt 5.15 LTS point releases. The first commercial-only Qt 5.15 LTS tagged release is expected to happen in February.

This policy change creates a concrete security risk for open-source Qt consumers, most critically KDE Plasma. Qt 5.15 LTS is the foundation for KDE Plasma 5.x, and with security patches now behind a commercial paywall, any CVE discovered in Qt 5.15 requires KDE developers to independently identify, patch, and backport the fix rather than receiving it from upstream. The Qt Company's rationale is commercially sound -- LTS support is the primary incentive for enterprise customers to purchase licenses, and providing it for free undercuts that value proposition. However, the LGPL exception for Qt WebEngine and Qt Script reveals the legal constraint: components containing LGPL-licensed third-party code cannot be restricted to commercial-only distribution. This tension between open-source sustainability and commercial viability is a recurring pattern in dual-licensed projects (MySQL/MariaDB, Redis/Valkey, Elasticsearch/OpenSearch), and often accelerates community forks.

Linus Torvalds Criticizes Intel for Blocking Consumer ECC RAM

Linus argues that error-correcting code (ECC) memory "absolutely matters" but that "Intel has been instrumental in killing the whole ECC industry with its horribly bad market segmentation... Intel has been detrimental to the whole industry and to users because of their bad and misguided policies wrt ECC. Seriously...The arguments against ECC were always complete and utter garbage... Now even the memory manufacturers are starting to do ECC internally because they finally owned up to the fact that they absolutely have to. And the memory manufacturers claim it's because of economics and lower power. And they are lying bastards - let me once again point to row-hammer about how those problems have existed for several generations already, but these f*ckers happily sold broken hardware to consumers and claimed it was an 'attack', when it always was 'we're cutting corners'." Torvalds went on to say, "The 'modern DRAM is so reliable that it doesn't need ECC' was always a bedtime story for children that had been dropped on their heads a bit too many times. Yes, I'm pissed off about it. You can find me complaining about this literally for decades now. I don't want to say 'I was right'. I want this fixed, and I want ECC. And AMD did it. Intel didn't."

Intel's artificial segmentation of ECC support -- restricting it to Xeon processors and excluding consumer Core-series chips -- is a textbook example of market segmentation causing systemic harm. ECC RAM detects and corrects single-bit memory errors that occur due to cosmic ray bit-flips, electrical interference, and DRAM cell degradation. Studies from Google and CERN have measured error rates of approximately 25,000-75,000 single-bit errors per billion device hours per megabit, which means a 64 GB workstation experiences a correctable memory error roughly every few days. Without ECC, these errors silently corrupt data in applications, filesystems, and databases. AMD's Ryzen Pro and consumer Ryzen platforms support ECC (though with vendor-dependent motherboard validation), which is why Torvalds specifically praises AMD. The Rowhammer vulnerability Torvalds references is directly relevant: it exploits the electrical coupling between adjacent DRAM rows to flip bits intentionally, and ECC makes this attack significantly harder to execute reliably.

Java ZGC Moves Thread Stack Processing to Concurrent Phase

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past. We have, so far, moved all GC operations that scale with the size of the heap and the size of metaspace out of safepoint operations and into concurrent phases. Those include marking, relocation, reference processing, class unloading, and most root processing. The only activities still done in GC safepoints are a subset of root processing and a time-bounded marking termination operation. The roots include Java thread stacks and various other thread roots. These roots are problematic, since they scale with the number of threads. With many threads on large machines, root processing becomes a problem.

JEP 376 addresses ZGC's last remaining scalability bottleneck: thread stack scanning during safepoint pauses. Before this change, ZGC achieved sub-millisecond pause times for heap operations (marking, relocation, reference processing) but still paused all application threads to scan their stacks for GC roots. On applications with thousands of threads -- common in Kotlin coroutine-based and virtual-thread-heavy microservices -- this root scanning phase could push pause times from sub-millisecond into multi-millisecond territory, negating ZGC's core value proposition. By moving thread stack processing into a concurrent phase using stack watermarks (lazy per-frame scanning as threads resume), ZGC achieves truly O(1) pause times regardless of heap size, metaspace size, or thread count. This makes ZGC competitive with manual memory management for latency-sensitive workloads such as trading systems and real-time audio processing, while preserving the safety and productivity advantages of garbage collection.

Fedora 33 Wins 50% of Benchmarks Against Clear Linux and Ubuntu

Out of 110 tests run across the four distributions, Fedora Workstation 33 won half of them, followed by Clear Linux leading in 30% of the tests, and then Ubuntu 20.10 and Manjaro 20.2 each winning roughly 10% of the time.

Fedora 33's benchmark dominance on Tiger Lake hardware reflects its aggressive adoption of newer compiler toolchains (GCC 10.2, glibc 2.32) and kernel versions that include Intel-specific optimizations before other distributions backport them. Clear Linux's 30% win rate is notable because Intel specifically tunes it for their hardware with custom compiler flags (-O3, PGO, LTO across the entire package set), so Fedora outperforming it suggests that kernel-level scheduling and I/O improvements outweigh per-package compilation optimizations for many workloads. However, benchmark performance is a poor predictor of operational fitness. The decisive factors for a production OS choice are update policy (Fedora's 13-month lifecycle versus Ubuntu LTS's 5-year support), package ecosystem breadth, and upstream governance. Fedora's role as Red Hat's community upstream means its technology choices directly preview what will appear in RHEL 2-3 years later, making it valuable as an early indicator of enterprise Linux direction.

JEP 388: OpenJDK AArch64 Port Brings Native Java to Windows on ARM

We have ported the JDK to Windows/AArch64, by extending the work previously done for the Linux/AArch64 port (JEP 237). This port includes the template interpreter, the C1 and C2 JIT compilers, and garbage collectors (serial, parallel, G1, Z and Shenandoah). It supports both the Windows 10 and Windows Server 2016 operating systems. The focus of this JEP is not the porting effort itself, which is mostly complete, but rather the integration of the port into the JDK main-line repository.

JEP 388 highlights a recurring pattern in Java platform development: the Linux AArch64 port (JEP 237) shipped years earlier and served as the foundation for both this Windows port and the macOS/AArch64 port (JEP 391). The porting effort itself is architecturally interesting because it required adapting AArch64 code generation for Windows-specific calling conventions (the Windows ARM64 ABI differs from the Linux AAPCS64 ABI in register usage, stack alignment, and structured exception handling). Including all five garbage collectors (Serial, Parallel, G1, ZGC, Shenandoah) means Windows ARM devices such as the Surface Pro X and Qualcomm-powered laptops get full JVM feature parity from day one, rather than a reduced-capability interpreter-only mode. This is particularly relevant for enterprise environments deploying Java server applications on ARM-based Windows Server instances in cloud environments.

Wasmer 1.0 RC: WebAssembly Runtime for Desktop and Server Workloads

Wasmer 1.0 is approaching release as the open-source WebAssembly runtime for desktops and server-side WASM execution as a "universal runtime" outside of the web browser. Wasmer has made significant progress over the past year toward the 1.0 milestone. Following the beta earlier this month that added Apple Silicon (M1) support and other improvements, this WebAssembly macOS, Windows, and Linux runtime has reached the release candidate phase with numerous fixes.

Wasmer 1.0 RC reaching Apple M1 support at launch is strategically important: it means WebAssembly modules compiled from Rust, C, or Go run natively on ARM64 macOS without Rosetta 2 translation overhead. Unlike the JVM, which bundles a garbage collector, class loader, and runtime library weighing hundreds of megabytes, a WASM runtime like Wasmer is measured in single-digit megabytes and executes pre-compiled modules with near-native speed through its Cranelift or LLVM JIT backends. The security model is fundamentally different from both the JVM and containers: WASM modules have zero default capabilities and must be explicitly granted access to specific filesystem paths, network interfaces, or environment variables through the WASI capability model. This makes Wasmer suitable for executing untrusted third-party code in plugin systems, serverless functions, and edge compute nodes where container startup latency (typically 100ms-1s) is unacceptable and WASM cold-start times (sub-millisecond) provide a decisive advantage.

Rust, Kotlin, Python