Une version du projet Wifibox 0.10 est disponible pour résoudre le problème de l'utilisation par FreeBSD d'adaptateurs sans fil dépourvus des pilotes nécessaires. Les adaptateurs qui posent problème pour FreeBSD sont fournis en exécutant un invité Linux, qui charge les pilotes de périphériques sans fil Linux natifs.
L'installation du système invité avec les pilotes est automatisée et tous les composants nécessaires sont regroupés sous la forme d'un package wifibox prêt à l'emploi, qui est lancé au démarrage à l'aide du service rc fourni. Y compris le passage en mode veille est correctement traité. L'environnement peut potentiellement être appliqué à toutes les cartes WiFi prises en charge sous Linux, mais a été testé principalement sur des puces Intel. Nous avons également testé le bon fonctionnement sur des systèmes équipés de puces sans fil Qualcomm Atheros et AMD RZ608 (MediaTek MT7921K).
Le système invité est lancé à l'aide de l'hyperviseur Bhyve, qui organise la redirection d'accès vers la carte sans fil. Nécessite un système prenant en charge la virtualisation matérielle (AMD-Vi ou Intel VT-d). Le système invité est basé sur la distribution Alpine Linux, construite sur la bibliothèque système Musl et l'ensemble d'utilitaires BusyBox. La taille de l'image est d'environ 30 Mo sur le disque et consomme environ 90 Mo de RAM.
Pour se connecter à un réseau sans fil, le package wpa_supplicant est utilisé, dont les fichiers de configuration sont synchronisés avec les paramètres de l'environnement FreeBSD principal. Le socket Unix de contrôle créé par wpa_supplicant est transmis à l'environnement hôte, ce qui vous permet d'utiliser les utilitaires FreeBSD standard pour vous connecter et travailler avec un réseau sans fil, y compris les utilitaires wpa_cli et wpa_gui (net/wpa_supplicant_gui).
Dans la nouvelle version, le mécanisme de transfert de WPA vers l'environnement principal a été repensé, ce qui a permis de travailler à la fois avec wpa_supplicant et hostapd. La quantité de mémoire requise pour le système invité a été réduite. Abandon de la prise en charge de FreeBSD 13.0-RELEASE.
De plus, on peut noter un travail d'amélioration des pilotes pour les cartes sans fil basées sur les puces Intel et Realtek, proposées dans FreeBSD. Avec le soutien de la Fondation FreeBSD, le développement se poursuit sur le nouveau pilote iwlwifi inclus avec FreeBSD 13.1. Le pilote est basé sur le pilote Linux et le code du sous-système Linux net80211, prend en charge 802.11ac et peut être utilisé avec les nouvelles puces sans fil Intel. Le pilote est chargé automatiquement au démarrage lorsque la bonne carte sans fil est trouvée. Les composants de la pile sans fil Linux sont alimentés par la couche LinuxKPI. Auparavant, le pilote iwm était porté sur FreeBSD de la même manière.
En parallèle, le développement des pilotes rtw88 et rtw89 pour les puces sans fil Realtek RTW88 et RTW89 a commencé, qui sont également développés en portant les pilotes correspondants depuis Linux et fonctionnent à l'aide de la couche LinuxKPI. Le pilote rtw88 est prêt pour les tests initiaux, tandis que le pilote rtw89 est encore en cours de développement.
De plus, on peut mentionner la publication de détails et d'un exploit fini lié à la vulnérabilité (CVE-2022-23088) dans la pile sans fil FreeBSD, corrigé dans la mise à jour d'avril. La vulnérabilité permet au code d'être exécuté au niveau du noyau en envoyant une trame spécialement conçue lorsque le client est en mode d'analyse du réseau (à l'étape précédant la liaison SSID). Le problème est causé par un débordement de tampon dans la fonction ieee80211_parse_beacon() lors de l'analyse des trames balises transmises par le point d'accès. Le débordement a été rendu possible par l'absence de vérification que la taille réelle des données correspond à la taille spécifiée dans le champ d'en-tête. Le problème se manifeste dans les versions de FreeBSD formées depuis 2009.
Parmi les récents changements de pile non sans fil dans FreeBSD : les optimisations du temps de démarrage, qui ont été réduites de 10 secondes à 8 secondes sur le système de test ; implémentation du module GEOM gunion pour transférer sur un autre disque les modifications effectuées sur un disque disponible en mode lecture seule ; pour l'API de chiffrement du noyau, les primitives cryptographiques XChaCha20-Poly1305 AEAD et curve25519 requises pour le pilote VPN WireGuard ont été préparées.
Source: opennet.ru