Rust 1.81. Obstakels bij de promotie van Rust in de Linux-kernel

De release van de veelzijdige programmeertaal Rust 1.81 is uitgebracht, oorspronkelijk ontwikkeld door Mozilla, maar nu beheerd door de onafhankelijke non-profitorganisatie Rust Foundation. De taal richt zich op veilig geheugenbeheer en biedt middelen voor hoge parallelle uitvoering van taken, zonder gebruik te maken van een garbage collector en runtime (runtime beperkt zich tot basisinitialisatie en ondersteuning van de standaardbibliotheek).

Geheugenmethoden in Rust helpen ontwikkelaars om fouten bij het manipuleren van pointers te voorkomen en beschermen tegen problemen die voortkomen uit laag-niveau geheugenwerk, zoals toegang tot geheugen na vrijgave, derefereren van null pointers, buffer overflows, enz. Voor het verspreiden van bibliotheken, het garanderen van builds en het beheren van projectafhankelijkheden is er een pakketbeheerder genaamd Cargo ontwikkeld. Voor het plaatsen van bibliotheken wordt de repository crates.io ondersteund.

Veilige geheugenwerking in Rust wordt tijdens de compilatie gegarandeerd door middel van referentiecontrole, het bijhouden van eigenaarschap van objecten, het in acht nemen van de levensduur van objecten (scope) en het evalueren van toegangsrechten tot geheugen tijdens de uitvoering van code. Rust biedt ook middelen om integer-overflows te voorkomen, vereist dat waarden van variabelen voor gebruik worden geïnitialiseerd, behandelt fouten beter in de standaardbibliotheek, past het concept van onveranderlijke (immutable) referenties en variabelen als standaard toe en biedt sterke statische type-onderzoek voor het minimaliseren van logische fouten.

Belangrijkste vernieuwingen:

• De trait core::error::Error is gestabiliseerd, die de foutbeschrijvingen definieert. Deze wijziging maakt het mogelijk om een uniforme Error trait te gebruiken in verschillende bibliotheken, ongeacht de omgeving, inclusief bibliotheken die niet zijn gekoppeld aan de standaardbibliotheek en het attribuut ‘#![no_std]’ gebruiken.
• Stabiele en ongestabiliseerde sorteerfuncties in de standaardbibliotheek zijn overgestapt op nieuwe algoritmen die een hogere snelheid en kortere compilatietijd laten zien. In de implementatie van de nieuwe sorteeralgoritmen is het mogelijk gemaakt om ongeldig gedefinieerde traits Ord te identificeren en in dergelijke gevallen een fout (panic) te genereren in plaats van willekeurig gegroepeerde gegevens.
• In de linter is een nieuw controle-niveau ‘expect’ (‘#[expect(lint)]’) geïmplementeerd, waarmee je kunt verifiëren of de controle is uitgevoerd en een waarschuwing kunt genereren als de controle niet is uitgevoerd (door een fout in de implementatie of het uitschakelen van de controle). Bijvoorbeeld, bij het overzetten van de codebase naar het gebruik van de controle undocumented_unsafe_blocks via Clippy, kan je ‘#[expect(clippy::undocumented_unsafe_blocks)]’ opgeven om te verzekeren dat alle unsafe-blokken gedocumenteerd zijn tijdens de overgang. In Clippy zijn ook controles clippy::allow_attributes en clippy::allow_attributes_without_reason geïmplementeerd, die het vervangen van het attribuut ‘#[allow]’ door ‘#[expect(lint)]’ vergemakkelijken.
• Mogelijkheid geboden om de reden voor het vervangen van controle-niveaus (lint) te documenteren, wat nieuwe ontwikkelaars informatie biedt over de redenen voor het toevoegen van een bepaalde controle, weergegeven als een compilatormelding. Bijvoorbeeld: #![deny(clippy::float_arithmetic, reason = “no hardware float support”)]
• Een nieuwe lading API's is gestabiliseerd, inclusief gestabiliseerde methoden en implementaties van traits:
  • 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

  Het teken «const», dat de mogelijkheid bepaalt om in elke context in plaats van constanten te worden gebruikt, is toegepast in functies:

  • char::from_u32_unchecked (functie)
  • char::from_u32_unchecked (methode)
  • CStr::count_bytes
  • CStr::from_ptr

  Het type std::panic::PanicInfo is hernoemd naar std::panic::PanicHookInfo (de werking van de oude naam blijft behouden, maar met de volgende versie zal het gebruik leiden tot een waarschuwing). Het type core::panic::PanicInfo blijft zoals het is, maar zal zich ontwikkelen als een apart type. Het scheiden van de typen stelt ons in staat om verschillende methoden te implementeren, specifiek voor gebruik in de context van snd en no_std.

• De overgang naar ABI C-unwind (‘extern «C-unwind»‘) is afgerond, die verschilt van de ABI zonder de suffix «-unwind» (‘extern «C»‘) door veilig gedrag (safe) te behouden wanneer het proces van ‘unwinding’, geïnitieerd bij een crash of bij het genereren van een uitzondering in C++-stijl, de ABI-grens overschrijdt (bijvoorbeeld wanneer een uitzondering die is opgetreden in code geschreven in de ene programmeertaal, tijdens het uitpakken de stack aanraakt die gerelateerd is aan code geschreven in een andere programmeertaal). Met de release van Rust 1.81 is in ABI ‘extern «C»‘ ongecontroleerd beëindigen ingeschakeld bij niet-gevangen unwinding.
• Derde niveau ondersteuning is geïmplementeerd voor platforms i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Derde niveau betekent basisondersteuning, maar zonder geautomatiseerd testen, publicatie van officiële builds en verificatie van de mogelijkheid om de code te bouwen.
• Tweede niveau ondersteuning is geïmplementeerd voor doelplatforms loongarch64-unknown-linux-musl en arm64ec-pc-windows-msvc. Tweede niveau ondersteuning garandeert dat het bouwen mogelijk is.
• Voor Linux-systemen op het LoongArch-platform is volledige tooling en profiler beschikbaar gesteld.
• Een kwetsbaarheid (CVE-2024-43402) in std::process::Command is verholpen, die zich alleen op het Windows-platform manifesteert en een exploitatiegat van een eerder verholpen kwetsbaarheid genaamd BatBadBut oplost, gerelateerd aan de verwerking van speciale tekens bij het gebruik van aanroepen van Command::arg en Command::args, die zijn ontworpen voor de directe overdracht van argumenten aan een proces, zonder dat ze door de command interpreter worden verwerkt. Tijdens de uitvoering van bat- en cmd-scripts werd het proces cmd.exe gestart, dat een eigen logica voor argumentindeling heeft. De omzeiling van de bescherming is gebaseerd op het feit dat Windows leidende spaties en punten in paden verwijdert, dat wil zeggen, een bestand met de extensie '.bat. .' wordt behandeld als '.bat'.

Daarnaast is het vermeldenswaardig dat Wedson Almeida Filho zijn functie als maintainer van het Rust for Linux-project heeft neergelegd, wat zich richt op de integratie van ontwikkeltools voor de Rust-taal in de Linux-kernel. Na het vertrek van Wedson zijn er nog twee maintainers overgebleven — Miguel Ojeda, de auteur en hoofdontwikkelaar van het Rust-for-Linux-project, en Alex Gaynor, de voormalige directeur van de Python Software Foundation, die de overstap naar Rust heeft gemaakt. De vertrekkende maintainer, die zich vier jaar geleden bij het project voegde, is een medewerker van Microsoft en de auteur van een experimentele driver met een implementatie van het EXT2-bestandssysteem, geschreven in Rust. Laatstelijk was Almeida's werk gericht op het ontwikkelen van tools voor het bouwen van bestandssystemen in Rust. Dit jaar heeft Almeida 17 commits in de Rust-for-Linux-repository aangebracht (ter vergelijking, Miguel Ojeda heeft 53 commits toegevoegd).

Als reden voor zijn vertrek wordt een gebrek aan energie en enthousiasme genoemd, die ooit aanwezig waren om te reageren op bepaalde niet-technische nonsens. Volgens Almeida zijn ontwikkelaars gedwongen veel energie te besteden aan discussies over irrelevante zaken, wat de belangrijkere globale doelstellingen ondermijnt. Almeida blijft geloven in de toekomst van de kernel met het gebruik van talen die veilige geheugenwerking garanderen, en als de Linux-ontwikkelaarsgemeenschap dit niet begrijpt, zal Linux door een andere kernel worden vervangen, zoals eerder met Unix is gebeurd.

De aanhangers van het Rust-for-Linux-project hebben te maken gekregen met de noodzaak om het verzet te overwinnen van gevestigde, oudere kernelontwikkelaars die de noodzaak om een nieuwe taal te leren niet zien. In zijn ontslagbrief verwijst Almeida naar een discussie die heeft plaatsgevonden tijdens de presentatie van Almeida en Kent Overstreet op de "Linux Storage, Filesystem, Memory-Management, and BPF Summit" en die gewijd was aan het gebruik van Rust voor de ontwikkeling van bestandssystemen. Ted Ts’o, de auteur van de ext2/ext3/ext4 bestandssystemen, bekritiseerde de introductie van Rust en vergeleek het Rust-for-Linux-initiatief met de poging om iedereen te dwingen de religie van Rust te omarmen.

In reactie op Almeida's voornemen om een wrapper boven de C-interfaces van bestandssystemen te creëren voor gebruik in Rust-code, merkte Ted Ts’o op dat een dergelijke wrapper onvermijdelijk tot problemen zou leiden, aangezien elke wijziging in C-interfaces en herstructurering een wijziging van de wrapper voor Rust zou vereisen. Hij wil niet de extra verantwoordelijkheid op zich nemen voor het oplossen van problemen in de Rust-code en het bijhouden van de status van de Rust-wrapper. C-code ontwikkelt zich voortdurend en als een wijziging niet meer compatibel is met de Rust-wrapper, zou dit ook de werking van alle gekoppelde bestandssystemen in gevaar brengen.

Ted gelooft ook dat de wrapper voor Rust op de korte termijn secundair zal blijven en dat problemen in de bindings slechts een hoofdpijndossier zullen zijn voor de ontwikkelaars van Rust-for-Linux, en niet voor de bredere gemeenschap van kernel-bestandssysteemontwikkelaars. Het is vermeld dat niet alle ontwikkelaars van plan zijn om Rust te leren en dat zij, na wijzigingen die andere code beïnvloeden, alleen de afhankelijkheden in C kunnen bijwerken, maar niet de Rust-wrappers, omdat ze Rust niet kennen. Ook James Bottomley, die de SCSI-subsysysteem beheert, voegde zich bij de discussie en vertelde dat hoe meer semantiek er in wrappers wordt gecodeerd, hoe fragieler ze worden in termen van synchronisatie.

Ondertussen heeft Google vorig jaar de pvmfm-firmware, die in Rust is herschreven, gebruikt in virtuele machines, uitgevoerd op het Android-platform, deelden hun ervaring over het geleidelijk integreren van code geschreven in Rust in bestaande firmware, oorspronkelijk geschreven in C of C++. Er is aangetoond hoe de beveiliging van firmware aanzienlijk kan worden verbeterd door identieke vervangcomponenten te creëren, geschreven in Rust. Bij de introductie van Rust wordt aangeraden om de focus te leggen op het gebruik van Rust voor nieuwe code en code die functies uitvoert die cruciaal zijn voor de veiligheid (bijvoorbeeld code voor het verwerken van externe gegevens van onbetrouwbare bronnen). Voor de integratie van Rust- en C-code wordt aanbevolen om schimmels (shim) te gebruiken die aanroepen tussen de Rust- en C-API vertalen (de C-API wordt geëxporteerd voor gebruik in Rust-code en omgekeerd), waardoor het mogelijk is om geleidelijk API-elementen naar Rust te herschrijven.

Bron: opennet.ru