Écrire un chargeur d’amorçage BIOS pour le mode 64 bits

• Les gens distinguent les choses complexes de celles qui sont simplement compliquées. La complexité est perçue comme intéressante, tandis que le caractère compliqué est jugé nuisible. Le processus de configuration d’un CPU x86_64 relève surtout du compliqué.
• L’article explique comment configurer le CPU, depuis un secteur d’amorçage chargé par le BIOS, pour passer du mode réel 16 bits au mode long 64 bits. Cette configuration reste basique et nécessite davantage de travail.
• Il faut le manuel du développeur logiciel des architectures Intel 64 et IA-32, un assembleur (avec nasm) et QEMU. Il faut aussi connaître l’assembleur x86 et la syntaxe de nasm.

Point de départ : BIOS

• Après un reset, un CPU x86 se trouve en « mode réel ». Ce mode utilise une taille d’opérande par défaut de 16 bits. Il permet d’adresser 1 Mo de mémoire via la segmentation.
• Le premier code exécuté après le BIOS se trouve dans le secteur d’amorçage. Le BIOS cherche le premier secteur du système qui se termine par 0xaa55, puis charge ce secteur d’amorçage à l’adresse mémoire 0x7c00.
• Le BIOS ne fournit que 512 octets, qu’il faut utiliser pour amorcer le reste du bootloader.

Configuration du secteur d’amorçage

• L’auteur met en place un secteur d’amorçage simple qui utilise des routines BIOS pour afficher un message à l’écran puis s’arrêter. Cela permet de vérifier que les outils fonctionnent.
• Le secteur d’amorçage est configuré à l’aide de code assembleur et d’un Makefile.

Étape 1 – Charger l’étape 2 depuis le disque

• Le bootloader peut être divisé en deux étapes. L’étape 1 correspond au code du secteur d’amorçage, c’est-à-dire tout ce que le BIOS charge. Son seul objectif est de charger l’étape 2 en mémoire.
• Dans l’étape 2, on passe du mode réel 16 bits au mode protégé 32 bits. En mode protégé, les routines BIOS ne sont plus disponibles. Charger des secteurs depuis le disque devient bien plus complexe.
• L’article explique comment accéder au disque via le BIOS.

Mode protégé 32 bits

• Le CPU passe du mode réel (16 bits) au mode protégé (32 bits). En mode protégé, la segmentation sert à mettre en place la protection mémoire.
• Avant de basculer en mode protégé, il faut définir une table globale des descripteurs (GDT). La GDT est définie en mémoire comme une structure contiguë.
• L’article explique comment définir la GDT et passer en mode protégé.

Mode long 64 bits

• Avant de passer en mode long, le CPU doit être en mode protégé et la pagination doit être activée. Le mode protégé est déjà configuré, mais la pagination reste nécessaire.
• La pagination remplace la segmentation pour gérer l’espace d’adressage virtuel, les permissions, etc. L’article explique comment créer les tables de pages nécessaires au passage en mode long.
• L’article explique comment définir la GDT pour le mode long et comment passer du mode protégé au mode long.

Résumé de GN⁺

• Cet article décrit en détail le processus de configuration d’un CPU x86_64, du mode réel 16 bits au mode long 64 bits. Il permet de mieux comprendre le développement de bootloaders et de noyaux de système d’exploitation.
• Il couvre divers concepts comme le BIOS, le secteur d’amorçage, le mode protégé et le mode long, et fournit pour chaque étape le code assembleur et les méthodes de configuration nécessaires.
• Cet article sera utile aux personnes intéressées par le développement de systèmes d’exploitation, en particulier à celles qui veulent acquérir une compréhension approfondie de l’architecture x86. Un projet proposant une fonctionnalité similaire est « Writing a Simple Operating System – from Scratch ».

[GN⁺]

Commentaires Hacker News

• Il existe un moyen de passer en mode long sans basculer d’abord manuellement en mode protégé
  • Quelqu’un a créé un bootloader qui charge dans le secteur d’amorçage un petit noyau 64 bits
  • Cela inclut le chargement du noyau depuis le disque et la configuration du mode VESA
• Le 80286 disposait du MSW, un registre 16 bits, et le 80386 l’a étendu en CR0 sur 32 bits
  • Le mode long 64 bits a ajouté le MSR EFER et a étendu CR0 à 64 bits
  • Actuellement, seuls 11 bits de CR0 et 8 bits d’EFER sont utilisés
  • On se demande pourquoi Intel/AMD n’ont pas utilisé les bits libres des registres existants
• La partie la plus inutilement complexe de l’article est le Makefile et le script de l’éditeur de liens
  • NASM peut produire une sortie binaire plate, mais l’auteur semble penser que l’utiliser est trop « bidouillé »
• Toutes les étapes nécessaires pour faire passer le CPU dans le bon mode sont inutilement complexes
  • Elles semblent toutes nécessaires pour la rétrocompatibilité
  • Intel aurait pu fournir dès le départ un drapeau ou une instruction permettant de démarrer directement dans le bon mode
  • Ou bien supprimer toute la rétrocompatibilité
  • Quelqu’un se souvient avoir étudié si ARM64 avait un problème similaire
  • On se demande s’il existe un CPU conçu en 64 bits dès le départ
  • C’était probablement l’un des objectifs/de la philosophie de conception d’Itanium
• Il y aura sans doute des partisans de l’UEFI qui ne comprendront pas pourquoi créer une nouvelle approche de bootloader
  • Comme le dit l’auteur, « si vous êtes arrivé jusqu’ici, c’est déjà formidable »
• On se demande depuis combien de temps l’UEFI existe
  • C’est dommage que le BIOS n’ait pas été abandonné en même temps que l’arrivée du mode long
• On se demande si cette procédure de démarrage est compatible avec EFI/UEFI
  • On se demande si le superviseur UEFI émule réellement les modes réel/protégé/long sur le matériel réel
• On se demande si ce processus est plus simple sur ARM