Discussion :

[Apitronix]

Salut à tous !
Existe-t-il un endroit où on peut trouver la liste des appels systèmes linux (et / ou windows), ainsi que leur code en assembleur ? ( write : 4, read = 3, etc)
J'ai fureté un peu sur le web, et je n'ai rien trouvé de convaincant, donc si vous avez ça, je suis preneur !

[Apitronix]

Je viens à l'instant de trouver ce lien, qui résume quel appel correspond à quelle valeur, mais je ne suis pas bien sûr qu'il soit à jour...
http://www.lxhp.in-berlin.de/lhpsysc0.html

Quelqu'un sait comment cette personne / organisation sait que read = 3, write = 4, open = 5, etc ?

[xdelatour]

Bonjour,

Sinon j'ai trouvé ce lien : https://git.kernel.org/pub/scm/linux...alls.h?id=HEAD

En gros, le plus simple pour Linux est de chercher dans le code source du noyau, c'est gratuit !
Pour les constantes il faut plutôt chercher dans les fichiers include (*.h)

Quant à Windows, pas sûr que ce soit facile à trouver, ce sont peut-être des dll qui sont plus utilisées que des appels systèmes.

[BufferBob]

salut,

en complément à ce qu'a répondu xdelatour, c'est en général autour du fichier unistd.h que ça se joue, un exemple ici pour un kernel dont j'ignore la version, sous archi x86 : https://github.com/spotify/linux/blo...sm/unistd_32.h

dans tous les cas comme indiqué toutes les réponses sont dans le code du noyau et ses headers, le tout est disponible, y'a plus qu'à chercher, expliquer le pourquoi/comment nécessiterait un bon gros chapitre sans parler des exceptions selon les architectures et au fil des évolutions du noyau

pour résumer ~très~ grossièrement, chaque syscall porte un numéro, le noyau a en interne une table sur laquelle il aiguille le processeur, par ailleurs il dispose de macros permettant de spécifier si l'appel système prend 1, 2, 3 ou plus paramètres, ainsi l'appel à open(arg1, arg2) se transformera en interne en syscall3(__NR_open, arg1, arg2), et l'ABI du noyau permettra ensuite de s'y retrouver, typiquement le premier argument proviendra toujours de l'accumulateur (le registre ax/eax/rax) etc.

quant à Windows effectivement c'est un tout autre fonctionnement, sans parler de l'API native, le principe est effectivement de charger la bonne DLL et appeler la fonction qui va bien par son nom explicite (et non pas un numéro comme sous Linux), par exemple MessageBox() alias de MessageBoxA, ou MessageBoxEx etc.

l'API Windows est décrite dans la MSDN

[Apitronix]

Merci beaucoup pour le coup de main !

Je bosse sur linux bien plus que sur windows, de toute façon.
On peut retrouver une version de "unistd_32.h" sur les versions compilées du noyau je pense. Non ?
Parce que j'ai passé deux minutes à chercher, mais j'ai rien trouvé sur la 4.9.X. Mais je vais tenter de fouiller plus en profondeur.
Vous m'avez ôtés une belle épine du pied,
merci encore.

Ben.

[BufferBob]

On peut retrouver une version de "unistd_32.h" sur les versions compilées du noyau je pense. Non ?

d'abord unistd_32.h ne concerne que les architectures 32bits (ce qui mine de rien se fait de plus en plus rare), ensuite on trouve le fichier dans les headers, pas dans le code du noyau en tant que tel (c'est subtil...) c'est en général un paquet à part (donc vérifier s'ils sont bien installés)
sur le fs, les headers sont en général du coté de /usr/include/ tandis que les sources du noyau (non installées par défaut) sont plutôt du coté de /usr/src/linux/

j'ai rien trouvé sur la 4.9.X.

oui ben voilà, une spécificité parmi d'autres, le fichier unistd_{32,64}.h a disparu pour cette architecture, mais on peut retrouver ses petits en tapant du coté de syscall_32.tbl par exemple

[Apitronix]

Merci pour le lien.

En fouillant encore un peu, j'ai trouvé un forum où ils conseillaient d'installer les headers de sa version du noyau :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo apt-get install linux-headers-4.9.0-6-common

Et d'utiliser la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo -n "#include <sys/syscall.h>\nSYS_read" | gcc -E -

Elle m'a retournée une liste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "<stdin>"
<stdin>:1:25: warning: extra tokens at end of #include directive
# 1 "/usr/include/x86_64-linux-gnu/sys/syscall.h" 1 3 4
# 24 "/usr/include/x86_64-linux-gnu/sys/syscall.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/asm/unistd.h" 1 3 4
# 12 "/usr/include/x86_64-linux-gnu/asm/unistd.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/asm/unistd_64.h" 1 3 4
# 13 "/usr/include/x86_64-linux-gnu/asm/unistd.h" 2 3 4
# 25 "/usr/include/x86_64-linux-gnu/sys/syscall.h" 2 3 4
 
# 1 "/usr/include/x86_64-linux-gnu/bits/syscall.h" 1 3 4
# 32 "/usr/include/x86_64-linux-gnu/sys/syscall.h" 2 3 4
# 1 "<stdin>" 2

Et en fouillant dans ces dossiers, "/usr/include/x86_64-linux-gnu/asm/" pour être précis, j'ai trouvé deux fichiers plutôt contradictoires. Les fichiers "unistd_32.h" et "unistd_64.h". Le premier, je suppose, correpond aux machines fonctionnant en 32 bits, et le second aux 64. Chacune a une numérotation différente pour las appels système.
Cependant, je suis sur une machine 64 bits, comme l'indique "/proc/cpuinfo" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
clflush size    : 64
cache_alignment : 64

Et le code assembleur reprenant les numéros des appels système 32 bits fonctionne. Je suppose donc que le second fichier, pour les machines 64 bits ne fonctionne pas chez moi.
La question étant :
Pourquoi ?

[BufferBob]

Et d'utiliser la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo -n "#include <sys/syscall.h>\nSYS_read" | gcc -E -

je vois pas l'intérêt de cette commande, un find /usr/include/x86_64-linux-gnu/ -name "unistd*" fonctionnait aussi bien, même mieux en fait...

je suis sur une machine 64 bits, comme l'indique "/proc/cpuinfo" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
clflush size    : 64
cache_alignment : 64

ça n'a rien à voir. fais un file /bin/bash tu seras fixé

le code assembleur reprenant les numéros des appels système 32 bits fonctionne. Je suppose donc que le second fichier, pour les machines 64 bits ne fonctionne pas chez moi.
La question étant :
Pourquoi ?

donc tu poses une question sur la base d'un truc que tu n'as pas vérifié

le plus plausible c'est qu'en fait les syscalls 32bits fonctionnent parce que tu passes par l'instruction (vieille) int 0x80, c'est une compatibilité descendante, mais si tu écris ton code avec l'instruction (plus récente) syscall ce sont les numéros des syscalls 64bits qu'il faudra utiliser

c'est compliqué l'assembleur, Linux, l'assembleur sous Linux, et j'ai pas vocation à faire un cours complet, j'imagine qu'à ce stade on a pas trop mal répondu à ta question initiale, pour le reste je t'invite à prendre le temps d'apprendre, chercher, faire des erreurs par toi-même, c'est bien plus formateur que quand quelqu'un nous l'explique et internet regorge de docs bien foutues sur le sujet (pas comme pour Windows)