Издание Rust 1.81. Препятствия при интеграция на Rust в ядрото на Linux.

Обявен е релиз на езика за програмиране с общо предназначение Rust 1.81, който е основан от проекта Mozilla, но в момента се развива под покровителството на независимата неправителствена организация Rust Foundation. Езикът е фокусиран върху безопасната работа с паметта и предоставя средства за постигане на висок паралелизъм при изпълнението на задачи, като същевременно не използва събирач на боклук и runtime (runtime се свежда до основна инициализация и поддръжка на стандартната библиотека).

Методите за работа с паметта в Rust освобождават разработчиците от грешки при манипулиране на указатели и ги защитават от проблеми, произлизащи от ниско ниво работа с паметта, като достъп до освободена памет, разыменоване на нулеви указатели, излизане извън границите на буфера и др. За разпространение на библиотеки, осигуряване на компилация и управление на зависимостите проектът продължава да развива пакетния мениджър Cargo. Поддържа се хранилище за библиотеки на crates.io.

Безопасната работа с паметта в Rust се осигурява по време на компилацията чрез проверка на референтите, проследяване на притежанието на обекти, вземане под внимание на времето на живот на обектите (област на видимост) и оценка на коректността на достъпа до паметта по време на изпълнението на кода. Rust също така предоставя средства за защита срещу препълване на цели числа, изисква задължителна инициализация на стойностите на променливите преди тяхната употреба, по-добре обработва грешките в стандартната библиотека, прилага концепцията за неизменяемост (immutable) на референтите и променливите по подразбиране и предлага силна статична типизация за минимизиране на логическите грешки.

Основни нововъведения:

• Стабилизирана е характеристиката core::error::Error, която определя описанията на грешки. Промяната позволява използването на единна характеристика Error в различни библиотеки, независимо от средата, вкл. и в библиотеки, които не са свързани със стандартната библиотека, използващи атрибута «#![no_std]».
• Стабилните и нестабилните функции за сортиране в стандартната библиотека са преобразувани да използват нови алгоритми, демонстриращи по-висока скорост на работа и по-кратко време за компилация. В реализацията на новите алгоритми за сортиране е осигурено определение на некоректно дефинирани характеристики Ord и извеждане на грешка (panic) в такива случаи вместо случайно групирани данни.
• В linter-а е реализирано ново ниво на проверка «expect» («#[expect(lint)]»), което позволява да се уверите, че проверката е изпълнена и да извеждате предупреждение, ако проверката не е премината (поради грешка в реализацията или деактивиране на проверката). Например, при превод на кодовата база за използване на проверката undocumented_unsafe_blocks чрез Clippy, можете да зададете «#[expect(clippy::undocumented_unsafe_blocks)]», за да се уверите, че всички unsafe блокове ще бъдат документирани по време на прехода. В Clippy също са реализирани проверки clippy::allow_attributes и clippy::allow_attributes_without_reason, опростяващи замяната на атрибутите «#[allow]» с «#[expect(lint)]».
• Предоставена е възможност за документиране на причините за замяна на нивата на проверка (lint), предоставяйки на новите разработчици информация за причините за добавянето на конкретна проверка, извеждани под формата на съобщение от компилатора. Например: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
• Нов набор от API е преведен в категорията стабилни, включително стабилизирани методи и реализации на типажи:
  • core::error
  • hint::assert_unchecked
  • fs::exists
  • AtomicBool::fetch_not
  • Duration::abs_diff
  • IoSlice::advance
  • IoSlice::advance_slices
  • IoSliceMut::advance
  • IoSliceMut::advance_slices
  • PanicHookInfo
  • PanicInfo::message
  • PanicMessage

  Признак «const», представящ, който позволява използването му в различни контексти вместо константи, се прилага във функциите:

  • char::from_u32_unchecked (функция)
  • char::from_u32_unchecked (метод)
  • CStr::count_bytes
  • CStr::from_ptr

  Тип std::panic::PanicInfo е преименуван в std::panic::PanicHookInfo (работата на старото име е запазена, но от следващата версия, използването му ще води до изход на предупреждение). В същото време core::panic::PanicInfo ще остане непроменен, но ще се развива като отделен тип. Разделянето на типовете ще позволи реализирането на различни методи, специфични за изпълнение в контекста на snd и no_std.

• Завършен е преходът към ABI C-unwind (‘extern «C-unwind»‘), който се различава от ABI без суфикс «-unwind» (‘extern «C»‘) чрез запазване на безопасното поведение (safe), ако процесът на «размотаване» (unwinding), иницииран при аварийно завършване на програмата или генериране на изключение в стил C++, пресича границата на ABI (например, когато изключение, възникнало в код на един език за програмиране, при размотаване засяга стека, свързан с код на друг език за програмиране). От версия Rust 1.81 в ABI ‘extern «C»‘ е задействано аварийно завършване при неперехванато размотаване.
• Реализирано е трето ниво на поддръжка за платформите i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Третото ниво предполага базова поддръжка, но без автоматизирано тестване, публикуване на официални сборки и проверка на възможността за изграждане на кода.
• Реализирано е второ ниво на поддръжка за целевите платформи loongarch64-unknown-linux-musl и arm64ec-pc-windows-msvc. Второто ниво на поддръжка предполага гаранция за изграждане.
• За Linux-системи на платформата LoongArch е предоставен пълен инструментариум и профилировчик.
• Устранена е уязвимост (CVE-2024-43402) в std::process::Command, проявяваща се само на платформата Windows и отстраняваща заобиколен път за експлоатация на вече коригирана уязвимост BatBadBut, свързана с обработката на специални символи при използване на повикванията Command::arg и Command::args, предназначени за пряка предаване на аргументите на процеса, без тяхното обработване от командния интерпретатор. На практика, при стартиране на bat- и cmd-скриптове, се стартира процес cmd.exe, който има своя собствена логика за разделяне на аргументите. Заобикалянето на защитата е основано на това, че Windows премахва водещите интервали и точки в пътищата, т.е. файл с разширение «.bat. .» се обработва като «.bat».

Освен това, можем да отбележим напускането на Уедсон Алмейда Фильо (Wedson Almeida Filho) от поста на координатор на проекта Rust за Linux, който се занимава с внедряване на средства за разработка на езика Rust в ядрото на Linux. След напускането на Уедсон, в проекта останаха още двама координатори — Мигел Охеда (Miguel Ojeda), автор и основен разработчик на проекта Rust-for-Linux, и Алекс Гейнор (Alex Gaynor), бивш директор на Python Software Foundation, който премина на работа по популяризиране на Rust. Напусналият координатор, който се присъедини към проекта преди 4 години, работи в компанията Microsoft и е автор на експериментален драйвер за файловата система EXT2, написан на Rust. В последно време работата на Алмейда беше съсредоточена върху създаването на средства за разработка на файлови системи на Rust. Тази година Алмейда е добавил 17 комита в хранилището Rust-for-Linux (за сравнение, Мигел Охеда е добавил 53 комита).

Като причина за напускането се споменава липсата на сили и ентусиазъм, които някога са били достатъчни за реагиране на някои нелепости с не технически характер (nontechnical nonsense). Според Алмейда, разработчиците са принудени да вложат много усилия в спорове по незначителни въпроси, които обезсилват по-важната глобална цел. Алмейда все още вярва, че бъдещето на ядрата е свързано с използването на езици, които осигуряват безопасна работа с паметта, и ако общността на разработчиците Linux не разбере това, Linux ще бъде изместен от някое друго ядро, както се случи с Unix.

Поддръжниците на проекта Rust-for-Linux се сблъскват с необходимостта да преодолеят съпротивата на опитните стари разработчици на ядра, които не виждат необходимостта да учат нов език. В писмото си за напускане, Алмейда дава за пример дискусия, която се проведе по време на представянето на Алмейда и Кент Оверстрита (Kent Overstreet) на конференцията "Linux Storage, Filesystem, Memory-Management, and BPF Summit" и беше посветена на използването на Rust за разработка на файлови системи. Дейността по внедряване на Rust беше критикувана от Тед Цо (Ted Ts’o), автор на файловите системи ext2/ext3/ext4, който сравни инициативата Rust-for-Linux с опит да се принудят всички да приемат религията Rust.

В отговор на намерението на Алмейда да създаде обвивка над интерфейсите за файлови системи, написани на C, за използване в код на Rust, Тед Цо посочи, че такава обвивка неминуемо ще доведе до проблеми, тъй като всяка промяна в C-интерфейсите и провеждането на рефакторинг ще изискват промяна в обвивката за Rust, и той не иска да поема допълнителна отговорност за коригиране на възникналите проблеми в кода на Rust и следене на състоянието на Rust-обвивката. Кодът на C постоянно се развива и ако промяната му наруши работата на обвивката за Rust, това ще доведе до нарушаване на работата и на всички свързани с тази обвивка файлови системи.

Тед също така смята, че в обозримо бъдеще обвивката за Rust ще остане второстепенна, и възникващите проблеми в свързването ще бъдат главоболие само за разработчиците на Rust-for-Linux, а не за общността на разработчиците на файлови системи в ядрото. Уточнено е, че не всички разработчици са готови да изучават Rust, и следователно след промени, оказващи влияние на друг код, те ще могат да актуализират само зависимия код на C, но няма да могат да поправят Rust-обвивките, тъй като не знаят Rust. Дискусията също така беше подкрепена от Джеймс Ботъмли (James Bottomley), който управлява подсистемата SCSI, който каза, че колкото повече семантика е кодирана в обвивките, толкова по-крехки стават те от гледна точка на осигуряване на синхронизация.

Междувременно, компанията Google, която миналата година пренаписа въвеждането pvmfm, използвано в виртуални машини, стартиращи на платформата Android, споделиха опит за постепенното интегриране на код на езика Rust в съществуващите фърмуери, първоначално написани на C или C++. Показано е как може значително да се увеличи защитата на фърмуерите, създавайки идентични по функционалност компоненти замествания, написани на Rust. Основното внимание при внедряването на Rust се предлага да се насочи към използването на Rust за нов код и код, изпълняващ функции, критични за сигурността (например, код за обработка на външни данни, получени от недостоверни източници). За интеграция на код на Rust и C се предлага да се използват прослойки (shim), които трансилират повиквания между API на Rust и C (C API се експортира за употреба в кода на Rust и обратно), което позволява постепенно пренаписване на елементи от API на Rust.

Източник: opennet.ru