Издание на 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 при ‘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 for 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.

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

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

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

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