Discussion :

[Pragmateek]

Salut!

Quelques questions sur l'impossibilité d'utiliser les interruptions DOS ou Bios en mode protégé sous Windows:

1) Les fonctions de l'API ne font elles que wrapper les interruptions en assurant une meilleure sécurité?

2) Dans ce cas la prog assembleur ne perd t'elle pas un peu de son intérêt si il est impossible d'interagir directement, c'est à dire au niveau le plus bas, avec la machine, à moins d'utiliser des moyens détournés (hook, driver)?

3) Cela induit il une perte de portabilité, puisque le code est maintenant dépendant, en plus de l'architecture du processeur, du système d'exploitation?

4) Comment utiliser de la meilleure manière les interruptions en mode protégé?

5) N'y a t'il vraiment plus aucun intérêt à utiliser les interruptions directement?

Merci.

[ALT]

Quelques réponses :
La gestion des interruptions ne peut plus se faire comme sous DOS, puisque le système est multitâche.
Les routines du BIOS étaient déjà lentes en 16 bits...
Donc appeler une fonction du BIOS n'accélère pas le traitement.
Et il n'y avait pas besoin de l'assembleur pour ça, les langages plus évolués permettant d'appeler les "interruptions" (routines) du BIOS comme du système d'exploitation.
Néanmoins, l'assembleur reste utile pour réaliser rapidement des tâches très répétitives, afin d'améliorer les temps de traitement.
La programmation, en assembleur ou pas, si elle est proche de la machine, n'autorise aucune portabilité, en dehors de la famille de PC pour laquelle c'est développé. À moins de prévoir des pilotes pour tous les périphériques utilisés.

Quant à utiliser les interruptions en direct, il y a un risque de plantage, puisque le système peut avoir besoin du périphérique ou que l'interruption est souvent partagée par plusieurs périph. À mon avis, il vaut mieux utiliser les routines système, qui sont normalement prévues pour gérer les éventuels conflits.

Néanmoins, dans une fenêtre console DOS, il est tout à fait possible d'utiliser les interruptions, y compris en mode protégé, car ladite console est prévue pour assurer la liaison avec le reste du système &, donc, d'éviter les conflits.

Pour ce qui est de la programmation sous interruptions en mode protégé, il y avait jadis une littérature abondante. Exemples : PC interdit, ou La Bible du PC...

Moralité : dans un système multitâche, il faut abandonner les habitudes (pas toujours saines, d'ailleurs) de la programmation en mode monotâche.

Voilà ce que je peux en dire, de mémoire.
À vérifier, sans doute.

[Neitsa]

Bonjour

1) Les fonctions de l'API ne font elles que wrapper les interruptions en assurant une meilleure sécurité?

En gros, oui, mais toutes les fonctions de l'API n'utilisent pas forcément les interruptions.

Voilà schématiquement le processus d'appel lors d'un CreateFile() de l'API windows :

- CreateFile() [kernel32.dll]
- NtCreatFile() [ntdll.dll]
- ZwCreatfile() [ntdll.dll] (transition ring3 / ring0)
- ZwCreateFile() [ntoskrnl.exe] (kernel de windows)
- Passage d'une IRP du Kernel vers le(s) driver(s) de disque.
- Interruption (enfin )

Des milliers de lignes de codes ont été exécutées avant l'interruption proprement dites (notamment pour le passage de paramètres et afin de s'assurer que la sécurité du système n'était pas compromise).

2) Dans ce cas la prog assembleur ne perd t'elle pas un peu de son intérêt si il est impossible d'interagir directement, c'est à dire au niveau le plus bas, avec la machine, à moins d'utiliser des moyens détournés (hook, driver)?

De ce coté là c'est vrai. Mais l'assembleur ne sert pas qu'à appeler des routines d'interruption. Tout ce qui est programmation système ou encore des choses impossible à faire même en C requièrent encore l'assembleur (programmation SSE / SIMD / 3DNow! (bien qu'il ait les instrinsics), protection d'exécutable via SMC, etc.)

3) Cela induit il une perte de portabilité, puisque le code est maintenant dépendant, en plus de l'architecture du processeur, du système d'exploitation?

Pour ce qui est du mode protégé , l'assembleur est toujours directement lié à l'O.S puisqu'on ne peut se passer de l'API pour faire un programme.
Mais finalement la portabilité des langages de haut niveau compilé en natif ( C / C++, Delphi , etc.) ne se fait qu'au niveau des sources à cause de cela. Un malloc() sous Windows appel l'API VirtualAlloc() en interne, ce qui sera différent sous un unixoïde, même si au final le résultat est le même.

4) Comment utiliser de la meilleure manière les interruptions en mode protégé?

Les ints sous Windows c'est plus que fortement prohibés à mois d'en avoir une utilité très forte.
La seule raison apparente que je vois pour vouloir directement coder en utilisant des ints c'est de vouloir court-circuiter le kernel de Windows en installant ses propres gestionnaires d'interruptions tournant en ring0 ou servir ("servicing") soit même ses propres requêtes.
En ring3, dans ce cas là, autant codé un driver répondant gérant les ISR (Interrupt Service Request).

5) N'y a t'il vraiment plus aucun intérêt à utiliser les interruptions directement?

En mode protégé sous Windows, je ne vois aucun intérêt. A part peut être deux interruptions, l'int1 et l'int3 pour la mise au point de programmes (respectivement debugging pas à pas et debug breakpoint).

Sinon comme le disais ALT, les programmes 16 bits qui utilisent les ints passent au travers de NTVDM (machine virtuelle 16 bits) mais ce n'est qu'un gigantesque wrapper sécurisé qui ne court cuircuite en aucune façon les système de Windows.

[Pragmateek]

Merci de vos réponses.

[Pragmateek]

Encore une question:

N'y a t'il plus aucun moyen de programmer proche de la machine sur les systèmes d'exploitation modernes, les interruptions étant réservés à ces systèmes ?

Autrement dit est-ce qu'il faut obligatoirement programmer au niveau du système d'exploitation, qui agit comme une machine virtuelle, et se baser entièrement sur son API?

Merci.

[ALT]

Vus nos messages précédents, tu as la réponse à ta question : tant que tu passes par un système multitâche, il n'y a que des inconvénients à être trop proche de la machine (adressage direct de la mémoire, par exemple), car tu risques un conflit avec ledit système.
Le seul avantage reste l'accélération de routines très répétitives (calculs, tris...) ou excessivement lentes (surtout pour le temps réel) afin d'en accélérer l'exécution.
Dans ces cas, il faut prendre quelques précautions (au minimum [de mémoire !] tout ce qui est indispensable pour que l'application soit compatible avec le mode protégé) afin d'éviter les conflits.

En dehors de ça, il n'y a plus trop d'intérêt (pour ne pas dire que c'est franchement dangereux) à programmer "très près de la machine".

[Neitsa]

Bonjour,

N'y a t'il plus aucun moyen de programmer proche de la machine sur les systèmes d'exploitation modernes, les interruptions étant réservés à ces systèmes ?

Autrement dit est-ce qu'il faut obligatoirement programmer au niveau du système d'exploitation, qui agit comme une machine virtuelle, et se baser entièrement sur son API?

C'est exactement ça . Les systèmes d'exploitation utilisent le concept d'anneaux de protection ("rings" en anglais) qui découlent directement du mode protégé.

Sous Windows et Linux (et quasiment tous les systèmes modernes), ces systèmes utilisent des anneaux, le ring0 et le ring3 qui correspondent respectivement au mode Kernel et au mode utilisateur.

Pour simplifier, il existe entre ces deux anneaux une barrière qui n'est franchissable sans limitation que dans un seul sens : du ring0 au ring3 (le Kernel à donc accès à toute la partie utilisateur).

Par contre le mode utilisateur n'a pas accès directement au Kernel (pour les soucis de sécurité évident que cela poserait). Comme seul le mode Kernel dispose de tous les services (écriture, lecture et bien plus...) que peut donner le système d'exploitation, le mode utilisateur demande ces services au Kernel via des portes autorisées : ces portes ne sont ni plus moins que les APIs.

Lorsque qu'un service proposé par le Kernel est trop dangereux (par exemple sous Windows, le Kernel dispose d'une fonction permettant d'agir directement sur le bios) l'API en mode utilisateur ne propose pas cette fonction, la sécurité en est donc renforcée.

Le mode protégé implémente d'autre protections évitant que des instructions système soit directement utilisées depuis le mode utilisateur. Par exemple, s'il reste possible de lire la table d'interruption (IDT) sous processeur x86-x64 en mode utilisateur (via l'instruction SIDT) il est impossible d'y écrire (ce qui comprometterait encore une fois la sécurité) via l'instruction LIDT.
Ce mécanisme est implémenté pour la famille x86 via le CPL (Current Privilege level) et le DPL (Descriptor Privilege Level).

Pour les O.S actuels, la quasi totalité des interruptions (via l'instruction INT) ont un CPL et un DPL de 0, ce qui fait qu'elles sont inutilisables depuis l'espace utilisateur.

Il existe néanmoins la possibilité de passer en ring0 en programmant des drivers qui ne sont, schématiquement, que des DLLs du Kernel, et qui fonctionnent donc en ring0 (CPL = 0 ; DPL = 0).

Mais même en programmant en mode Kernel on reste quand même subordonné à l'O.S, par exemple pour écrire un fichier ou en lire un. On peut tout de même s'adonner à un peu de programmation système dans ce cas là et s'amuser à bidouiller le kernel de l'O.S

Pour vraiment faire de la programmation système et programmer au plus bas, le mieux est encore de programmer soi-même son propre Kernel, mais ça c'est un aute paire de manches

[mat.M]

Bonjour,
Lorsque qu'un service proposé par le Kernel est trop dangereux (par exemple sous Windows, le Kernel dispose d'une fonction permettant d'agir directement sur le bios) l'API en mode utilisateur ne propose pas cette fonction, la sécurité en est donc renforcée.

Sauf peut-être fonctions non documentées de l'OS et il y en a ....

Des milliers de lignes de codes ont été exécutées avant l'interruption proprement dites (notamment pour le passage de paramètres et afin de s'assurer que la sécurité du système n'était pas compromise).
.

Merci Neitsa pour cette brillante demonstration.
Mode Troll on : et s'imaginer avec ces milliers de lignes de code le rajout d'autres milliers de lignes de code avec le framework .NET ou la Java Virtual MAchine

[mat.M]

Salut!

Quelques questions sur l'impossibilité d'utiliser les interruptions DOS ou Bios en mode protégé sous Windows:

1: comme le dit Neitsa un programme Dos 16bit est émulé avec une sorte de boite virtuelle MS-DOS qui alloue un pseudo espace de 640k
2: oui sinon cela risque d'être instable.

Pourquoi veux-tu faire des interruptions en mode protégé ?

[Pragmateek]

Pourquoi veux-tu faire des interruptions en mode protégé ?

Pour l'intérêt pédagogique et la liberté que cela offre même si cela revient à réinventer la roue.