Під час процесу обговорення розробників ядра linux про іl тема набору з виправлення для виправлення вразливостей Spectre в коді для роботи зі зв'язаними списками, стало зрозуміло для багатьох розробників це проблема можна було б вирішити легше, якби було дозволено в коді ядра C que відповідає новішій версії стандарту.
І це те, що в даний час код, доданий до ядра Linux, повинен відповідати специфікації ANSI C (C89), яка була сформована в 1989 році.
Ось чому проблема, пов'язана зі Spectre у коді було тому, що sя продовжував використовувати ітератор визначається окремо після циклу.
Незважаючи на загалом швидкий характер, проект ядра спирається на ряд старих інструментів. Хоча критики люблять зосереджуватися на широкому використанні електронної пошти спільнотою, можливо, більш значущим анахронізмом є використання 1989 року версії стандарту мови C для коду ядра, стандарту, який був кодифікований до початку проекту ядра понад 30 років тому. Схоже, що ця багаторічна практика може закінчитися, як тільки ядро 5.18, що очікується в травні цього року.
Згадується, що макрос використовується для перебору елементів зв'язаного списку, і оскільки ітератор циклу передається цьому макросу, він визначається за межами самого циклу і залишається доступним після циклу. Використання стандарту C99 дозволить розробникам визначати змінні для циклу в блоці for(), що дозволить вирішити проблему, не винаходячи обхідних шляхів.
На жаль, у ядрі є кілька місць, де цей список
Ітератор використовується після циклу, який розривається при такій зміні. На щастя
є скрипт use_after_iter.cocci, який можна використовувати для ідентифікації таких
місця розташування коду. Мені довелося трохи адаптувати сценарій, оскільки він зменшує false
позитивні моменти в оригінальному варіанті використання, але вони мають відношення до цього виправлення.Велика кількість повідомлених місць розташування коду використовує лише ітератор списку
цикл, якщо був ранній вихід (перерва/перехід), і тому їх немає
відповідні.
Зі свого боку, Лінус Торвальдс погодився з цією ідеєю щоб мати можливість реалізувати підтримку новіших специфікацій і далі запропонував перейти на ядро 5.18 для використання стандарту C11, випущеного в 2011 році.
Після цього під час попередньої перевірки монтаж на GCC і Clang в новому режимі пройшов без відхилень. Якщо не виникнуть непередбачувані проблеми через ретельніше тестування, сценарії збірки ядра 5.18 змінять параметр «–std=gnu89» на «–std=gnu11 -Wno-shift-negative-value».
Лінусу Торвальдсу цей патч не дуже сподобався, і він не бачив, як він пов'язаний із уразливими місцями у спекулятивному виконанні. Однак після того, як Кошель додатково пояснив ситуацію, Торвальдс погодився, що «це звичайна помилка, зрозуміла й проста» і сказав, що її слід виправити незалежно від більшої серії. Але потім він заглибився в справжнє джерело проблеми: те, що ітератор, переданий макросам обходу списку, повинен бути оголошений в області дії за межами самого циклу:
Основна причина такого роду неспекулятивних помилок полягає в тому, що історично у нас не було «оголошення змінних у циклах» у стилі C99. Отже, list_for_each_entry() - і всі інші - в основному завжди фільтрують останній запис HEAD з циклу, просто тому, що ми не могли оголосити змінну ітератора в самому циклі.
Також варто зазначити це розглянута можливість використання стандарту С17, але в цьому випадку необхідно буде збільшити мінімальну підтримувану версію GCC, оскільки включення підтримки C11 відповідає поточним вимогам для версії GCC (5.1).
В кінці кінців якщо вам цікаво дізнатись більше про це, ви можете перевірити деталі в наступне посилання.