Why Linus Won't Put a National Anti-Fraud Center in the Linux Kernel

A Seemingly "Reasonable" Absurd Proposal

A Zhihu user asked why Linus Torvalds doesn't add the National Anti-Fraud Center to the Linux kernel, arguing it would skip tedious authorization steps and protect users at the highest system privilege. At first glance the idea might sound plausible, but anyone who has written code immediately recognizes the flaw. It's akin to asking why not implant a chip in every brain so police can directly detect crime — safe in theory, but unacceptable in practice.

The Kernel Is Not a Dumping Ground

The Linux kernel is the core of the operating system, managing CPU scheduling, memory allocation, and hardware drivers. The anti-fraud center is application-layer business logic. Forcing it into the kernel is like embedding a refrigerator into a load-bearing wall during renovation — technically possible but completely unnecessary. Linus demands rigorous review for every line of kernel code; each patch must prove its value. The kernel prioritizes generality, stability, and security. Anti-fraud is a China-specific scenario; why should every Linux user worldwide pay for it? If this door opens, Americans would demand an FBI module, Russians an FSB module, and the kernel would become unusable.

Highest Privilege = Maximum Risk

The questioner casually suggests "guarding user safety with highest privilege." Anyone who has worked in large-scale systems knows privilege management is the first line of defense. The principle of least privilege dictates using ordinary permissions whenever possible, never root. Granting an application-layer function kernel-level privileges doesn't enhance security — it creates vulnerabilities. A kernel bug crashes the entire system. Can the anti-fraud center's code quality meet kernel standards? Its update frequency, iteration cycle, and business logic changes operate on a completely different rhythm. Updating a detection rule would require either recompiling the kernel (terrible user experience) or dynamically loading external logic (a direct security backdoor). Moreover, code with full kernel access can theoretically monitor calls, read chats, track location — who guarantees it only does anti-fraud? Is the code open source? Where is the audit mechanism?

The Cognitive Gulf Behind the Technical Problem

The truly frightening aspect isn't the technical absurdity but that the questioner doesn't realize there's a problem. They view "skipping tedious authorization steps" as a benefit. In reality, those "tedious authorization steps" protect privacy and data security. User consent isn't a nuisance; it's a right — control over one's own device. Once that right is stripped, your phone and computer no longer belong to you. This mindset is common in internet giants: product managers want all permissions default-on for conversion rates; developers want everything running as root for convenience. Excellent system design balances functionality and security, giving users choice instead of making choices for them.

The Underlying Logic of the Open-Source World

Linux became what it is today not by the will of any single nation or organization, but through global developer consensus. The core of that consensus: the kernel stays neutral; the application layer flourishes. Want to install an anti-fraud center? Fine — do it in user space. Antivirus, firewalls, parental controls — all belong in user space. The kernel provides mechanisms, not policies. It gives you capabilities but doesn't decide how you use them. That's why Linux runs on servers, phones, routers, and even Mars rovers: it's sufficiently general and sufficiently restrained. Once the kernel mixes in specific business logic, it loses that generality and becomes a special-purpose system for a single scenario.

The Technical Clarity Every Developer Needs

Ultimately, this question reflects the dilemma of many developers. We're chased by endless requirements, pressured by KPIs. Product wants this feature, the boss wants that metric, so we just code. Over time we forget to ask: Is this requirement reasonable? Is this design correct? A developer's value isn't just implementing requirements but guarding technical bottom lines. Some features simply shouldn't be built; some functions simply shouldn't be added. This isn't opposing business — it's ensuring long-term system health. Today you break architecture for a small feature; tomorrow the whole system becomes a mountain of technical debt. Linus is respected not because he's nice-tempered (he's famously abrasive), but because he defends the kernel's purity. He bluntly rejects unreasonable patches even from senior engineers at big companies. That persistence is true technical conviction.

Code example

来源丨
经授权
转自 良许Linux（ID：liangxulinux）
作者丨
良许