от live patching до аварийного ремонта после Meltdown и Spectrefrom live patching to the emergency repair after Meltdown and Spectre
Ветка открылась live kernel patching как символом зрелости индустриальной эксплуатации и провела следующие три года, превращая eBPF из узкоспециализированного фильтра пакетов в полноценную программируемую платформу — а затем почти целиком переключилась на аварийные патчи против Meltdown и Spectre, аппаратных уязвимостей, затронувших вообще все современные процессоры.The branch opened with live kernel patching as a symbol of industrial-operations maturity, and spent the next three years turning eBPF from a narrow packet filter into a full programmable platform — then spent much of its final year on emergency patches against Meltdown and Spectre, hardware vulnerabilities that hit essentially every modern CPU.
Ветка 4.x охватывает почти четыре года — с 12 апреля 2015 (4.0.0) до 23 декабря 2018 (4.20, последний нелонгтерм-релиз перед сменой номера на 5.0 в марте 2019). Модель разработки не менялась третий раз подряд: та же непрерывная схема, что и в 2.6/3.x. Содержательно ветка делится на два неравных периода. Первые два с половиной года (2015–2017) — органичное развитие: live patching доводится до продакшена, eBPF проходит путь от простого пакетного фильтра до JIT-компилируемой программируемой платформы для трассировки и наблюдаемости, добавляются OverlayFS, KASLR-доработки, файловые системы вроде EROFS. Последний год (2017–2018) — аварийный режим: раскрытие Meltdown и Spectre в январе 2018 заставило все LTS-ветки экстренно бэкпортировать Kernel Page Table Isolation (KPTI) и retpoline-митигации, отодвинув плановую разработку на второй план.The 4.x branch spans nearly four years — from April 12, 2015 (4.0.0) to December 23, 2018 (4.20, the last non-LTS release before the number changed to 5.0 in March 2019). The development model didn't change for the third time running: the same continuous scheme as 2.6/3.x. Content-wise the branch splits into two uneven periods. The first two and a half years (2015–2017) were organic growth: live patching gets production-hardened, eBPF goes from a simple packet filter to a JIT-compiled programmable platform for tracing and observability, and OverlayFS, KASLR refinements, and filesystems like EROFS arrive. The final year (2017–2018) was emergency mode: the January 2018 disclosure of Meltdown and Spectre forced every LTS branch to urgently backport Kernel Page Table Isolation (KPTI) and retpoline mitigations, pushing planned development to the back burner.
| версияversion | датаdate | что именно изменилосьwhat actually changed |
|---|---|---|
| 4.0.0 | 2015-04-12 | снова чисто нумерационный жест (см. 3.x) — по содержанию главное: фундамент live kernel patching, объединивший наработки SUSE (kGraft) и Red Hat (kpatch); OverlayFS с несколькими нижними слоями; DAX (обход кеша ядра для persistent memory); KASAN (динамический детектор ошибок памяти)again a purely numerical gesture (see 3.x) — the main content: the live kernel patching foundation, unifying SUSE's kGraft and Red Hat's kpatch; OverlayFS with multiple lower layers; DAX (bypassing the kernel cache for persistent memory); KASAN (a dynamic memory error detector) |
| 4.1 | 2015-06-21 | поддержка s390 (мейнфреймы) для live patching; для eBPF — JIT-компиляция байткода в машинный код (резкое ускорение выполнения) и динамическая трассировка через kprobess390 (mainframe) support for live patching; for eBPF — JIT compilation of bytecode into machine code (a sharp execution speedup) and dynamic tracing via kprobes |
| 4.4 | 2016-01-10 | LTS-релиз: доработки user namespaces и cgroups в сторону изоляции контейнеров — прямое продолжение линии, заложенной в 3.8LTS release: refinements to user namespaces and cgroups for container isolation — a direct continuation of the line started at 3.8 |
| 4.6 – 4.8 | 2016 | продолжение расширения eBPF — новые типы карт (maps) для обмена данными между ядром и userspace, первые программы для XDP (обработка пакетов на самом раннем этапе, до сетевого стека)continued eBPF expansion — new map types for kernel/userspace data exchange, the first XDP programs (packet processing at the earliest possible point, before the network stack) |
| 4.9 | 2016-12-11 | крупный LTS-релиз (шесть лет официальной поддержки) — впоследствии станет одной из самых распространённых баз Android Common Kernel; eBPF набирает зрелость как платформа для observabilitya major LTS release (six years of official support) — later becomes one of the most widely used Android Common Kernel bases; eBPF matures as an observability platform |
| 4.14 | 2017-11-12 | ещё одна LTS-ветка — уже через месяц (версия 4.14.11, декабрь 2017) получает первые бэкпорты KPTI, ещё до публичного раскрытия Meltdown/Spectre: патчи готовились втайне при соблюдении embargoanother LTS branch — within a month (version 4.14.11, December 2017) it receives the first KPTI backports, even before the public Meltdown/Spectre disclosure: the patches were prepared secretly under embargo |
| 4.15 | 2018-01-28 | первый обычный (не LTS) релиз, вышедший уже после публичного раскрытия уязвимостей (3 января 2018) — содержит зрелые KPTI и retpoline-митигации против Meltdown/Spectre как часть стандартной поставки, а не аварийный бэкпортthe first regular (non-LTS) release to ship after the public vulnerability disclosure (January 3, 2018) — contains mature KPTI and retpoline mitigations against Meltdown/Spectre as part of the standard release, not an emergency backport |
| 4.16 – 4.18 | 2018 | продолжение доработки Spectre-митигаций (обнаруживались новые варианты атаки — v1, v2, v3, v4 — на протяжении всего года), возврат к плановой разработке параллельно с латанием безопасностиcontinued refinement of Spectre mitigations (new attack variants — v1, v2, v3, v4 — kept surfacing throughout the year), a return to planned development alongside the security patching |
| 4.19 | 2018-10-22 | последний LTS-релиз ветки: начальная поддержка Wi-Fi 6, файловая система EROFS (read-only, для встраиваемых систем и Android), union mount filesystemthe branch's final LTS release: initial Wi-Fi 6 support, the EROFS filesystem (read-only, for embedded systems and Android), a union mount filesystem implementation |
| 4.20 | 2018-12-23 | последний релиз ветки вообще (не LTS, цикл разработки — всего 62 дня) — небольшой промежуточный шаг перед сменой номера на 5.0 в марте 2019the branch's absolute last release (non-LTS, a 62-day development cycle) — a small intermediate step before the number changed to 5.0 in March 2019 |
4.0.0 (12 апреля 2015) добавила фундамент Livepatch — механизма, позволяющего накатывать критические исправления безопасности на работающее production-ядро без перезагрузки. За этим стояли годы параллельной, местами конкурирующей работы: SUSE выпустила kGraft в феврале 2013, Red Hat представила kpatch месяцем позже. Оба проекта решали одну и ту же задачу разными способами — kpatch останавливал систему через stop_machine() и проверял стеки процессов на безопасность патчинга, kGraft обеспечивал consistency на уровне отдельных потоков и лениво мигрировал их к патченому состоянию на безопасных точках. Итоговый Livepatch объединил сильные стороны обеих моделей. Отдельно 4.0 принесла OverlayFS с поддержкой нескольких нижних слоёв — механизм, который через несколько лет станет стандартной файловой системой для образов контейнеров.4.0.0 (April 12, 2015) added the Livepatch foundation — a mechanism for applying critical security fixes to a running production kernel without a reboot. Behind it lay years of parallel, at times competing work: SUSE shipped kGraft in February 2013, Red Hat introduced kpatch a month later. Both projects solved the same problem differently — kpatch stopped the system via stop_machine() and inspected process stacks for patching safety, kGraft provided per-thread consistency and lazily migrated threads to the patched state at safe checkpoints. The resulting Livepatch combined both models' strengths. Separately, 4.0 brought OverlayFS with multi-layer support — a mechanism that within a few years would become the standard filesystem for container images.
Классический BPF появился ещё в 1992-м как узкоспециализированная виртуальная машина для фильтрации сетевых пакетов без копирования их в userspace, а в ядро Linux попал в 1997-м (с версии 2.1) — им пользовались tcpdump и iptables. Расширенная версия, eBPF, влилась в 3.18 (2014) трудами Алексея Старовойтова: 64-битные регистры вместо старых, десять регистров вместо двух, инструкция BPF_CALL для дешёвого вызова функций ядра — виртуальная машина, устроенная гораздо ближе к реальному железу. Именно ветка 4.x довела эту базу до полноценной платформы: 4.1 (июнь 2015) добавила JIT-компиляцию байткода в машинный код и динамическую трассировку через kprobes — теперь eBPF-программы можно было цеплять практически на любую точку ядра и получать данные без перекомпиляции. К 4.6–4.8 (2016) добавились новые типы карт для обмена данными между ядром и userspace и первые программы XDP — обработка сетевых пакетов на самом раннем этапе, до входа в обычный сетевой стек, что даёт минимальную задержку. То, что начиналось как инструмент для tcpdump, к концу 2016 года стало платформой для observability, security и сетевой обработки одновременно.Classic BPF dates back to 1992 as a narrow virtual machine for filtering network packets without copying them to userspace, and landed in the Linux kernel in 1997 (from version 2.1) — used by tcpdump and iptables. The extended version, eBPF, merged in 3.18 (2014) through Alexei Starovoitov's work: 64-bit registers instead of the old ones, ten registers instead of two, a BPF_CALL instruction for cheap in-kernel function calls — a virtual machine built much closer to real hardware. It was the 4.x branch that took this base to a full platform: 4.1 (June 2015) added JIT compilation of bytecode into machine code and dynamic tracing via kprobes — eBPF programs could now hook into practically any point in the kernel and pull data without recompiling. By 4.6–4.8 (2016), new map types for kernel/userspace data exchange arrived, along with the first XDP programs — network packet processing at the earliest possible point, before entering the regular network stack, giving minimal latency. What started as a tool for tcpdump had, by the end of 2016, become a platform for observability, security, and network processing all at once.
2016 год дал ветке два долгосрочных релиза подряд: 4.4 (10 января) и 4.9 (11 декабря). 4.4 продолжила линию user namespaces и cgroups в сторону лучшей изоляции контейнеров — прямое развитие 3.8. Но именно 4.9 получила самую длинную дистанцию влияния: шесть лет официальной поддержки сделали её одной из самых распространённых баз для Android Common Kernel — миллионы устройств годами работали на производных этой версии, независимо от того, какую версию Android они формально показывали пользователю. К этому моменту eBPF как платформа уже была достаточно зрелой, чтобы использоваться для полноценной observability, а не только для узких сетевых задач.2016 delivered two long-term releases back to back: 4.4 (January 10) and 4.9 (December 11). 4.4 continued the user-namespaces-and-cgroups line toward better container isolation — a direct extension of 3.8. But it was 4.9 that gained the longest reach: six years of official support made it one of the most widely used bases for the Android Common Kernel — millions of devices ran derivatives of this version for years, regardless of which Android version they formally showed the user. By this point eBPF as a platform was mature enough to be used for full observability, not just narrow networking tasks.
Летом 2017 года исследователи независимо друг от друга обнаружили класс уязвимостей в механизме спекулятивного исполнения, которым пользуются практически все современные процессоры для повышения производительности: CPU выполняет инструкции заранее, до того как точно известно, понадобится ли результат, и в определённых условиях следы этого выполнения можно извлечь через побочные каналы (тайминг кеша), даже если сама спекулятивная ветка потом отбрасывается. Meltdown (CVE-2017-5754) позволял непривилегированному процессу читать память ядра. Spectre (CVE-2017-5753, CVE-2017-5715) был опаснее в теории, потому что затрагивал не только Intel, но и почти все архитектуры, и защититься от него было структурно сложнее. Раскрытие планировалось на 9 января 2018 под embargo, но Google объявила уязвимости публично уже 3 января, после того как слухи начали просачиваться на несколько дней раньше графика. Ответ ядра — Kernel Page Table Isolation (KPTI, изначально называвшийся KAISER), полностью разделяющий адресные пространства ядра и пользователя, чтобы закрыть Meltdown, и retpoline — техника замены косвенных вызовов функций прямыми вызовами специальных thunk'ов при поддержке компилятора, чтобы смягчить Spectre. LTS-ветки 4.14 и 4.9 получили экстренные бэкпорты (4.14.11 и 4.9.75 соответственно) практически сразу после раскрытия, а первый штатный (не LTS) релиз с зрелыми митигациями «из коробки», 4.15, вышел 28 января 2018.In the summer of 2017, researchers independently discovered a class of vulnerabilities in speculative execution, a mechanism nearly every modern processor uses for performance: the CPU executes instructions ahead of time, before it's certain the result will be needed, and under certain conditions traces of that execution can be extracted via side channels (cache timing), even when the speculative branch is later discarded. Meltdown (CVE-2017-5754) let an unprivileged process read kernel memory. Spectre (CVE-2017-5753, CVE-2017-5715) was theoretically more dangerous because it hit not just Intel but nearly every architecture, and was structurally harder to defend against. Disclosure was planned for January 9, 2018 under embargo, but Google announced the vulnerabilities publicly on January 3, after rumors had started leaking a few days ahead of schedule. The kernel's response was Kernel Page Table Isolation (KPTI, originally called KAISER), fully separating kernel and user address spaces to close Meltdown, and retpoline — a technique replacing indirect function calls with direct calls to special thunks, with compiler support, to mitigate Spectre. The LTS branches 4.14 and 4.9 received emergency backports (4.14.11 and 4.9.75, respectively) almost immediately after disclosure, and the first regular (non-LTS) release shipping with mature mitigations out of the box, 4.15, landed January 28, 2018.
Патч 4.15 не закрыл тему — в течение всего 2018 года исследователи продолжали находить новые варианты спекулятивного исполнения (обозначавшиеся v1 через v4 и далее), и релизы 4.16–4.18 несли очередные раунды митигаций параллельно с обычной разработкой. К октябрю ситуация стабилизировалась достаточно, чтобы 4.19 (22 октября 2018), ставшая последней LTS-веткой линейки 4.x, смогла сосредоточиться на плановых возможностях: начальная поддержка Wi-Fi 6, файловая система EROFS для read-only сценариев (встраиваемые системы, часть Android-образов), union mount filesystem. Последний вообще релиз ветки, 4.20 (23 декабря 2018), был коротким промежуточным шагом — 62-дневный цикл разработки — перед сменой номера на 5.0 в марте 2019.The 4.15 patch didn't close the topic — throughout 2018 researchers kept finding new speculative-execution variants (labeled v1 through v4 and beyond), and releases 4.16–4.18 carried further rounds of mitigations alongside regular development. By October the situation had stabilized enough that 4.19 (October 22, 2018), which became the 4.x line's last LTS branch, could focus on planned features: initial Wi-Fi 6 support, the EROFS filesystem for read-only scenarios (embedded systems, part of Android images), a union mount filesystem. The branch's absolute last release, 4.20 (December 23, 2018), was a short intermediate step — a 62-day development cycle — before the number changed to 5.0 in March 2019.
К 4.20 ядро приобрело два свойства, которые определят следующее десятилетие: eBPF как полноценная программируемая платформа (JIT-компиляция, карты для обмена данными, kprobes, XDP), ставшая фундаментом для будущих инструментов observability и security за пределами ядра (Cilium, Falco, BCC/bpftrace появятся позже именно на этой базе), и Kernel Page Table Isolation как штатная, а не временная защита от целого класса атак через спекулятивное исполнение — цена этой защиты, ощутимая просадка производительности на syscall-интенсивных нагрузках, стала постоянной частью вычислительного бюджета для всех современных x86-систем. Live patching к этому моменту уже был production-инструментом, а не экспериментом. Модель разработки — та же непрерывная схема с 2.6, невзирая на то, что почти год пришлось потратить на аварийное реагирование, а не на плановые фичи.By 4.20 the kernel had gained two properties that would define the following decade: eBPF as a full programmable platform (JIT compilation, data-exchange maps, kprobes, XDP), becoming the foundation for future observability and security tools built outside the kernel (Cilium, Falco, BCC/bpftrace would all later build on exactly this base), and Kernel Page Table Isolation as a standard, not temporary, defense against a whole class of speculative-execution attacks — the cost of that defense, a noticeable performance hit on syscall-heavy workloads, became a permanent part of the compute budget for every modern x86 system. Live patching was already a production tool by this point, not an experiment. The development model remained the same continuous scheme from 2.6, despite nearly a year having to go toward emergency response instead of planned features.
Обе уязвимости — свойство физической реализации спекулятивного исполнения в самих процессорах, а не ошибка в коде ядра Linux. KPTI и retpoline — это программные обходные пути (workarounds), закрывающие последствия аппаратной проблемы ценой производительности, а не исправления бага в исходном смысле слова. Затронуты были все ОС на уязвимом железе — Windows, macOS, BSD получили аналогичные митигации примерно в те же сроки, что подчёркивает: проблема была в CPU, а не в конкретном ядре.Both vulnerabilities are a property of how speculative execution is physically implemented in the processors themselves, not a bug in the Linux kernel's code. KPTI and retpoline are software workarounds that close off the hardware problem's consequences at a performance cost, not bug fixes in the original sense of the word. Every OS on vulnerable hardware was affected — Windows, macOS, and BSD received analogous mitigations on roughly the same timeline, underscoring that the problem lived in the CPU, not in any particular kernel.
Название создаёт впечатление незначительного апгрейда классического BPF из 1990-х, но разница архитектурная: 64-битные регистры вместо узкой модели с двумя, вызов произвольных функций ядра через BPF_CALL, верификатор безопасности, карты данных для обмена состоянием — то, что раньше умело только фильтровать пакеты, стало платформой общего назначения для трассировки, security-мониторинга и сетевой обработки. Отождествлять «eBPF» с «tcpdump-фильтрами» — устаревшее на добрый десяток лет представление.The name creates an impression of a minor upgrade to classic 1990s BPF, but the difference is architectural: 64-bit registers instead of a narrow two-register model, calling arbitrary kernel functions via BPF_CALL, a safety verifier, data maps for exchanging state — what used to only filter packets became a general-purpose platform for tracing, security monitoring, and network processing. Equating "eBPF" with "tcpdump filters" is a good decade out of date.
4.9 действительно стала одной из самых распространённых баз Android Common Kernel, но производители устройств бэкпортируют патчи и держат конкретную версию ядра годами, независимо от того, какая версия Android (и с каким собственным номером) установлена поверх. Судить о возрасте или патч-уровне системы по единственной цифре версии ядра — та же ошибка, что и с RHEL 7 на «ядре 3.10» из ветки 3.x: номер версии в проде почти никогда не отражает буквальный набор апстрим-патчей без сверки с реальным changelog вендора.4.9 genuinely became one of the most widely used Android Common Kernel bases, but device makers backport patches and keep a specific kernel version for years, independent of whatever Android version (with its own separate number) sits on top. Judging a system's age or patch level from a single kernel version digit is the same mistake as RHEL 7 running "kernel 3.10" from the 3.x branch — a production version number almost never reflects the literal upstream patch set without checking the vendor's actual changelog.