Издание на Rust 1.96. Оценка на пригодността на Rust за създаване на фърмуер за микроконтролери

Публикувана версия 1.96 на програмния език Rust, който беше разработван от Mozilla, а сега се развива под благосклонността на независимата нестопанска организация Rust Foundation. Язикът е насочен към безопасна работа с паметта и предоставя средства за постигане на висок паралелизъм при изпълнението на задачи, без да изисква използването на сборщик на мусор или runtime (runtime е ограничен до основна инициализация и поддръжка на стандартната библиотека).

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

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

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

• Добавен е модул range с реализация на нови типове, разработвани за замяна на остарелите типове Range, RangeInclusive, RangeToInclusive и RangeFrom, които позволяват съхранение на диапазони в Copy структури. Типът Range определя диапазони, ограничени от минималната и максималната допустима стойност (но не включваща тези стойности), типът RangeFrom определя числа, започващи от указаната стойност, а типът RangeInclusive обозначава стойности от указания диапазон и включва и двете му граници. В бъдещи издания ще се добавят типове RangeFull и RangeTo, а старата реализация ще бъде преместена в core::range::legacy::*, като синтаксисът „N..M“ ще бъде адаптиран към новия вариант на типовете.

  Новите типове се отличават с това, че вместо типажа Iterator реализират типажа IntoIterator, т.е. определят как да се преобразува типът в итератор вместо да използват вградените итератори. Този подход позволява да се използва операцията за копиране с новите типове (типажът Copy, показващ, че стойностите на типа могат да се дублират с просто копиране), което по-рано беше недостъпно поради несъвместимост с типовете с вградени итератори.
  Например, новите типове дават възможност да се съхранят границите на среза в структура, която се копира напълно, без да се налага отделно запазване на началните и крайните стойности:

  use core::range::Range;

  #[derive(Clone, Copy)]
  pub struct Span(Range);

  impl Span {
  pub fn of(self, s: &str) -> &str {
  &s[self.0]
  }
  }

• Добавени са макроси «assert_matches!» и «debug_assert_matches!», които проверяват дали стойността съответства на указан шаблон и аварийно прекратяват изпълнението при несъответствие. Те се различават от изразите «assert!(matches!(..))» и «debug_assert!(matches!(..))» с извеждане на отладъчна информация за стойностите, предизвикали сбоя. За да се избегнат конфликти с външни макроси, доставяни с подобни имена, новите макроси изискват явен импорт на библиотеката «core::assert_matches».

  use core::assert_matches;

  fn get_random_number() -> u32 {
  4
  }

  fn main() {
  assert_matches!(get_random_number(), 1..=6);
  }

• При създаване на целева платформа WebAssembly, предаването на опцията на компоновчика «—allow-undefined», която позволяваше свързване при наличие на неопределени символи, които се преобразуваха в импорт от модула «env», е прекратено. При създаване за WebAssembly всички символи, свързани с компоновката, сега по подразбиране трябва да бъдат определени. За възстановяване на старото поведение може да се използва променлива на средата «RUSTFLAGS=-Clink-arg=—allow-undefined» или изразът ‘#[link(wasm_import_module = «env»)]’ в кода.
• В категорията стабилни е преведена нова порция API, като са стабилизирани методите и реализациите на типажите:
  • assert_matches!
  • debug_assert_matches!
  • From за AssertUnwindSafe
  • From за LazyCell
  • From за LazyLock
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter
• В пакетния мениджър Cargo е отстранена уязвимост CVE-2026-5223, която може да се използва за презапис на изходния код на друг crate пакет в локалния кеш на пакети от същия репозитория, чрез манипулации със символични връзки в самия crate. Уязвимостта се проявява само при работа със странични пакетни хранилища и не засяга потребителите на репозитория crates.io, тъй като в crates.io е забранено качването на пакети със символични връзки.

Допълнително може да се отбележи публикуването (PDF) на резултатите от анализа на пригодността на езика Rust за разработка на фърмуер за микроконтролери и вградени системи с ограничени ресурси.
Изследването е проведено от компанията STMicroelectronics с участието на няколко европейски университета. На две изолирани екипи от разработчици е била поставена задача за реализиране на една и съща фърмуер за микроконтролери STM32U585AI с ядро Arm Cortex-M33. Първият екип е създавал фърмуер на C, а вторият на Rust.

Тестовете на завършената работа не показаха значителни предимства при използването на езика C вместо Rust при разработката на фърмуери за микроконтролери, при сравнение на консумацията на памет и производителност. По-скоро, използването на системния runtime, написан на Rust от открития проект Ariel OS, позволи да се постигне консумация на памет в проекта на Rust под нивото на реализацията на C, използваща традиционен стек за разработка на фърмуери на базата на библиотеката newlib.

Размерът на финалния фърмуер бе 84100 байта за проекта на Rust и 76744 байта за проекта на C (с 10% по-малко), но консумацията на оперативна памет при фърмуера на Rust се оказа значително по-ниска — 24640 байта срещу 42608 байта. Що се отнася до производителността, при тестването на начални прототипи, разработени за 6 седмици, реализацията на Rust два пъти надминаваше реализацията на C, но и двете реализации значително изоставаха от изчислената максимална производителност. След 4 седмици, посветени на оптимизация, двете реализации достигнаха приблизително еднакви резултати, близки до изчисления максимум.

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