Champs Rust packed : éviter de créer une référence non alignée avant une conversion en pointeur brut

Ce que c'est

La documentation de read_unaligned de Rust avertit que prendre une référence vers un champ packed non aligné puis convertir cette référence en pointeur brut est déjà invalide. La référence intermédiaire doit elle-même être alignée. La syntaxe documentée d'adresse brute évite de créer cette référence, tandis que read_unaligned assouplit les exigences d'alignement pour la lecture. Rust read_unaligned

Pourquoi c'est important

Un agent peut raisonner qu'une référence utilisée un seul instant ne peut pas avoir d'importance. Ici, la validité s'applique au moment où la référence est formée. Examiner l'expression entière, pas seulement le type de pointeur final. Se demander aussi s'il est nécessaire d'interpréter une structure packed ou si un analyseur explicite d'octets exprimerait mieux le format.

Comment l'appliquer

• Identifier l'adresse réelle du champ et l'alignement requis à partir du contrat de disposition (layout). Garder la disposition native de la structure séparée de l'ordre des octets de tout fichier ou protocole externe.
• Chercher les expressions qui empruntent le champ, y compris le formatage de commodité ou les appels auxiliaires, avant d'auditer l'opération de lecture finale. Une conversion ultérieure ne peut pas annuler une référence antérieure invalide.
• Si une lecture brute non alignée est nécessaire, utiliser la construction documentée qui évite une référence, et justifier séparément la validité du pointeur, l'initialisation et la plage d'octets accessible.
• Pour de simples entiers de protocole, envisager de copier les octets requis dans une valeur explicitement décodée. Cela peut rendre visibles à la fois les bornes et l'ordre des octets à la frontière de l'analyseur.
• Proposer des fixtures avec le champ à des décalages diversement alignés, des tampons tronqués et des valeurs limites valides. Vérifier les chemins de rejet plutôt que le seul décodage réussi.

Pièges

read_unaligned ne valide pas des pointeurs arbitraires et ne fait pas d'un motif de bits invalide une valeur valide d'un type quelconque choisi. Dupliquer une valeur non-Copy avec une lecture brute exige également un raisonnement sur la propriété (ownership). Ne pas généraliser à partir d'un processeur qui tolère un chargement à la validité du langage Rust. Les vérifications décrites ici sont proposées et n'ont pas été exécutées pour cet article.