Archive·tdd.cat
PDF·11 Stories

The Daily Diff

An Engineering Newspaper · Curated by Arpit Bhayani

  /\_/\
 (=^.^=)
 (")_(")
				
  /\_/\
 (=^.^=)
 (")_(")
				

Section
Signal

No stories match the selected filters in today's edition.

Postgres select distinct queries scan every matching row

Postgres treats SELECT DISTINCT as a full scan problem regardless of how many unique values actually exist in your table. Even if you maintain a perfect B-tree index and only need ten distinct keys out of ten million rows, the query engine will dutifully read every single matching entry.

The root cause comes down to the lack of an index skip scan feature in Postgres. While databases like Oracle and MySQL can jump directly to the next distinct key within a B-tree, Postgres scans linearly through duplicate values before discarding them. For partitioned queue systems that poll for distinct active queues, this turns an intended low-latency operation into an IO bottleneck.

The standard production workaround is to emulate loose index scans using recursive common table expressions. A recursive query looks up the minimum key, jumps to the next value strictly greater than the current key via an index seek, and stops when no values remain.

Benchmarking this recursive approach against a raw SELECT DISTINCT routinely drops query durations from seconds down to sub-millisecond ranges.

A simple schema design cannot save you when query execution plans rely on full scans by default.

Writing shared objects to achieve RCE via SQLite dbpage

Achieving arbitrary file writes through SQLite has traditionally been blocked by the immutable one-hundred-byte database file header. While techniques using ATTACH DATABASE worked against permissive parsers like PHP, strict runtimes like Python or the dynamic linker reject files with SQLite magic bytes.

This barrier disappears when targets enable the sqlite_dbpage virtual table. By granting direct read and write access to raw database pages, sqlite_dbpage allows an attacker to rewrite the entire storage file at will, bypassing typical table schema validations.

The main obstacle remains the first one hundred bytes of page one, which SQLite continually overwrites with transaction metadata. The breakthrough here is relocating the Executable and Linkable Format (ELF) Program Header Table. Because the ELF specification permits moving the program header beyond the initial header offset, you can craft a fully valid shared object library inside an active database file without corrupting SQLite headers.

When arbitrary SQL allows rewriting storage pages, treating a database as an isolated sandbox is a dangerous assumption. Auditing internal SQLite compile flags like SQLITE_ENABLE_DBPAGE is essential for securing embedded data layers.

Why Buran needed four computers to survive two failures

Designing fault-tolerant systems forces hard trade-offs between hardware redundancy and voting algorithms. The Soviet Buran orbiter flew with four identical Biser-4 computers running synchronously, not the three typical of triple modular redundancy.

Why four? If a system must survive two failures and can only detect faulty channels by comparing outputs, four channels are strictly required. With three computers, a single failure leaves two nodes that can disagree without identifying the broken one. Buran solved this by using four identical nodes to ensure safe isolation across two consecutive faults. This differs subtly from classic Byzantine agreement bounds, where 3f + 1 nodes are needed to handle arbitrary malicious nodes. Buran relied on comparison-based blocking under crash-stop or silent failure assumptions.

However, identical redundancy introduces correlated software bugs. A software flaw present across all identical flight computers will still execute identically. To inspect the voter mechanism itself, the author implemented a Rust model and formally verified five theorems and two corollaries in Lean 4 via Aeneas.

Formal verification guarantees the voting logic behaves correctly, but it cannot fix common-mode failures if every node agrees on bad input. Redundancy without diversity remains a fragile safety net.

Fine-tuning model weights to teach agents specialized workflows is often slow, expensive, and difficult to maintain across model upgrades. SkillOpt approaches this problem from a completely different angle by treating the natural language skill document itself as the trainable state of a frozen agent.

Instead of touching neural network weights, the framework executes tasks across scored batches, records trajectory logs, and prompts an optimizer model to analyze failures. The optimizer then proposes structured additions, deletions, and replacements within the skill document. Proposed changes must survive a held-out validation gate before being accepted into the agent library.

This separation between the execution engine and procedural instructions mirrors how human standard operating procedures evolve. Engineering teams can systematically optimize complex tool orchestration without managing fragile fine-tuned checkpoints or relying on intuition-driven prompt tweaks.

Procedural optimization in text space offers a scalable, inspectable path for production agent reliability.

Giving autonomous AI agents access to third-party APIs usually requires pasting long-lived secrets into their environment, creating a severe blast radius if the agent encounters prompt injection.

Agent IAP solves this dilemma by introducing an identity-aware proxy pattern between ephemeral agent workers and upstream services. Instead of receiving raw API credentials, each agent runs inside an isolated virtual machine on a restricted network and holds only a temporary token minted by the proxy.

When the agent issues an outbound request to services such as Cloudflare or analytics providers, the proxy authenticates the caller, pulls the actual secret from 1Password on the fly, and injects the authorization header. The agent never observes the real secret in its context window, configuration files, or command execution logs.

Restricting access at the network boundary turns prompt injection from an existential credential leak into an easily remediated sandbox failure.

File notification APIs are standard building blocks across modern operating systems, yet their permission models leave glaring side-channel vulnerabilities. Research accepted at ACM CCS reveals that standard APIs such as inotify on Linux, FileObserver on Android, and ReadDirectoryChangesW on Windows allow unprivileged processes to infer sensitive user activities simply by monitoring metadata events.

On Linux, watching a readable directory exposes every event on nested files, including files that the watching process lacks permission to read directly. This design flaw allows an attacker to observe events in /dev/input and reconstruct inter-keystroke timing. On Android, FileObserver bypasses the per-application storage sandbox provided by FUSE, allowing applications to monitor media deletions and arrivals in third-party messaging directories. On Windows, querying the root directory C:\ exposes the full paths of files accessed anywhere across the filesystem, regardless of user boundaries.

Operating system abstractions frequently decouple data access permissions from event notification permissions. When designing background file monitors or local agents, engineers must account for these notification channels as active threat vectors rather than benign telemetry streams.

Default configurations in open-source prompt-injection firewalls fail almost completely when security threats are buried inside realistic tool outputs. In a recent benchmark testing ten popular detectors against 629 realistic AgentDojo attacks hidden in tool responses, the Prompt Guard 2 model from Meta detected only one percent of malicious payloads out of the box.

The issue is not that the model fails to detect the injection tokens. Instead, the default decision boundary assumes clean, stand-alone adversarial prompts rather than mixed execution contexts where legitimate JSON or HTML surrounds the payload. When engineers recalibrate the decision threshold from 0.50 down to 0.003 using held-out benign traffic, detection jumps from one percent to nearly one hundred percent across unseen domains with only a five percent false positive rate.

If you are designing security boundaries for autonomous agents, you cannot rely on vendor defaults tuned for user-facing chat windows. You must calibrate scoring thresholds against the specific noise distribution of your environment tool logs.

Safety filters are only as dependable as the distributions used to tune them.

Running autonomous agents in production without strict boundaries is a recipe for disaster. Most teams currently patch together ad hoc Docker commands or custom microVM harnesses to keep agentic code from wandering across the internal network. That fragmentation makes auditing permissions nearly impossible across different deployment environments.

Docker is taking a major step forward by donating its Sandbox Kit specification to the Cloud Native Computing Foundation. Instead of inventing a completely detached isolation protocol, the specification embeds an agent, its runtime tools, and an explicit permissions manifest directly into standard OCI container images. The manifest details the exact network endpoints, environment variables, credentials, and filesystem volumes the agent is allowed to access.

Because these restrictions live inside the container metadata itself, pulling an image cryptographic digest guarantees that you also pull its enforced policy boundaries. You can use your existing container registries, vulnerability scanners, and cryptographic image signing pipelines to verify agent privileges before execution.

Packaging permission boundaries directly into the deployment artifact is the missing foundation for safe autonomous execution.

Writing high-performance code in Go has historically required writing custom assembly whenever vectorization was needed. This approach fractured codebases, created severe maintenance overhead, and made cross-platform optimization impractical.

The Go team has introduced an experimental, platform-independent SIMD interface in recent releases that bridges this gap. Loosely modeled after Highway in C++, the new package abstracts away the deep structural differences between fixed-size architectures like AVX on x86 and variable-length vector designs on ARM.

Instead of binding code to specific register widths, engineers write vectorized algorithms against generic vector operations. The Go compiler translates these instructions into optimal hardware primitives like AVX-512 or NEON, while falling back to scalar emulation on unsupported platforms without breaking portability.

Internal runtime systems, including memory scanning in the Go garbage collector, already rely on SIMD to reduce overhead. Bringing native vectorization to standard library code unlocks substantial performance gains for data processing engines, cryptographic primitives, and database storage layers without sacrificing language safety.

Portable abstractions do not have to compromise on bare-metal throughput.

Decode throughput in large language models is fundamentally constrained by memory bandwidth rather than raw compute. When running autoregressive generation, moving model weights from high bandwidth memory into fast on-chip memory forms the primary latency bottleneck.

A recent breakthrough from Inferact demonstrates that TPU v7 hardware can significantly outperform NVIDIA GB200 GPUs on high-throughput serving. By implementing custom megakernels for Kimi K3 and Qwen models, the team achieved over 700 tokens per second with speculative decoding, compared to 452 tokens per second on the GB200 baseline.

The architectural secret lies in how the TPU exposes memory. Unlike the complex, hardware-managed cache hierarchies of modern GPUs, the TPU uses a large software-managed vector memory and a sequential execution model. This design allows engineers to build explicit asynchronous software pipelines that prefetch weights across layer boundaries before execution begins.

Hardware specialization only wins when the software layer directly controls data movement.

Traditional asynchronous runtimes in Rust rely heavily on readiness-based models like epoll, where tasks share a global thread pool and incur synchronization costs across CPU cores. Compio takes a different path by pairing a completion-based input and output architecture with a strict thread-per-core design.

Instead of waking a thread when a socket becomes ready and then issuing a read system call, Compio delegates the operation to modern completion APIs like io_uring on Linux and IOCP on Windows. The kernel takes ownership of the buffer, performs the transfer, and notifies the runtime only when the transaction finishes completely.

Pinning each worker thread to an individual core eliminates cross-thread task stealing overhead and locks. This operational model mirrors high-throughput database storage engines and network proxies that prioritize cache locality and predictable tail latency over dynamic work rebalancing.

Switching from reactor polling to pure completion queues fundamentally alters how engineers structure memory ownership in asynchronous systems.