salut à tous,
je voulais demander s'il est possible d'utiliser un appel system ( comme execve) dans un appel system que je veux ajouter dans un noyau linux . l'appel est du type:
#include <linux/linkage.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/unistd.h>
char *chemin[2];
char *arg_list[2];
asmlinkage int sys_mon_appel(int arg1, char* arg2){
char *chemin[0]="PATH=/home/gadiri";
char *chemin[1]=NULL;
char *arg_list[0]="./program";
char *arg_list[1]=NULL"
/*
--
*/
_syscall3(int,execve,const char *,filename,const char * ,arg_list,char *const,env); /*macro qui permet d'invoquer l'appel system dans l'espace noyau.
execve("./program",arg_list,chemin) ;
return(1);
}
cet appel system est sensé à son invocation executer le programme 'program'.
voila mais il n'affiche rien, l'appel system est valide j'ai mis des printk pour voir que le code s'execute. si quelqu'un pouvait m'aider se serait sympa
merci
Forum Programmation.c appel system execve dans fonction du noyau
12
août
2004
# Heuu
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 4.
C'est ton histoire de ps que tu veut integrer au noyau ?
Je veut pas etre desagreable, mais 1 qu'est ce que ca a a foutre en appel systeme et encore plus qu'est ce que ca fout dans le noyau.
et 2 le noyau il la connait deja la liste de processus qu'il fait tourner il a pas besoin de ps pour qu'on le lui dise.
Sinon sur la forme, je crois que tu devrait lire un peu plus de doc sur le fonctionnement du kernel avant de continuer tes bidouilles. Notamment la macros syscall3 n'a aucun usage dans le noyau, elle ne sert qu'aux programmes en mode user (glibc) pour contacter les procedures du kernel.
[^] # Re: Heuu
Posté par gadiri . Évalué à 1.
cette macro (syscall3)je l'ai mise car qd je compile le noyau, il indique 'warning: implicit declaration of function `execve. c'est pourquoi je l'ai integré. les includes que j'ai utilisé sont:
#include <linux/linkage.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/unistd.h>
à propos du "ps " ce problème là est fini, il s'agit d'autre chose.
je ne m'y connais pas très bien, vous l'aurez remarqué, et je bidouille effectivement. si je vous fais perdre votre temps, ne vous sentez pas obligé de repondre
merci
[^] # Re: Heuu
Posté par ge12345 . Évalué à 1.
a ce que je vois un sympathique garcon expérimente des trucs et essaye d'apprendre, sur ce, monsieur Plessis arrive et se permet de lui fermer sa gueule en le prenant de haut.
à te lire on a vraiment l'impression que gadiri n' a pas le DROIT de jouer avec quelque chose qui le dépasse, et comme de toute facon, il peut pas savoir ce qu'il fait, on essaie meme pas de comprendre.
c 'est peut etre pas faux ce que tu dis dans ton post, mais c'est pas des facons de parler à quelqu un qui demande poliment. t'as jamais été débutant, quand la grande majorité des trucs sont encore confus pour toi? c'est justement à ce moment là qu'on a besoin que les gens ne t'envoient pas te faire voir, c'est à cause de gens comme toi que les gens se découragent.
surtout que gadiri se montre admirablement calme apres ca.
on dirait que sous linux on est forcé de programmer que des trucs qui contribuent à améliorer linux... moi je programme pour le plaisir, pour faire des trucs moi meme, si ca sert ou pas je m en tape.
y a que les linuxiens qui disent rtfm dans les forums... pour un langage de prog ou une autre api ou OS, ca viendrait à l'idée de personne de dire ca! les forums/channels servent justement à demander à des gens, sans se taper toute la p#&~'! de doc! maintenant si tu ne daignes pas aider, tres bien ne poste pas ou dis "c est dans la faq"! ca te couterait pas plus de répondre, mais tu preferes poster un truc + long pour casser du nioub...
bravo.
[^] # Re: Heuu
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
oui aussi je suis d'accord tu as le droit de faire toutes les conneries
que tu veut. Mais je ne sais pas si tu a bien lu tout les messages de gadiri dans le forum et toutes les reponses qui lui on été faites.
Ce n'est pas ma premiere reponse et malgre tout ce qu'on lui dit il continue a faire des truc qui au premier abord sont assez delirants (demander au kernel d'executer un script shells dans un appel systeme ... ) sans vouloir (au moment ou j'ai repondu) expliquer ce qu'il veut vraiment.
Alors bon je me suis emporté, voila
Desolé gadiri mais tu me fait peur c'est tout et quand je vois le nombre de soft distribués ou sont appliqués tes methodes et bien je trouve cela dommage et je m'emporte.
[^] # Re: Heuu
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
moi j'ai l'honnete de donner mon nom et pas un pseudo debile ...
[^] # Re: Heuu
Posté par ge12345 . Évalué à 1.
désolé d avoir été un peu fort l'aut jour, c'est juste que la réponse m'avait un peu hérissé et je me suis souvenu que quand on commence en prog y a un paquet (la majorité des choses en fait) de trucs dont on ne saisit pas les tenants et les aboutissants, malheureusement la seule chose à faire c'est de s'accrocher... fatalement on va faire des trucs un peu absurde avant de comprendre comment tout marche...
mais bon c'est tres courageux d'essayer.
à la fin on comprend les trucs...
bonne journée!
(ps: moi meme je connais pas trop nux héhé... dsl. )
[^] # Re: Heuu
Posté par ge12345 . Évalué à 1.
# Execve dans sle noyau???
Posté par Pascal . Évalué à 4.
Mort de rire....
Execve remplace le code du processus courant par un autre code contenu dans un fichier executable.
Dejà le noyau n'est pas vraiment un processus. C'est ce qui permet justement de gérer les processus.
Et puis, si tu arrivais à remplacer le code en mémoire du noyau par le code de ps, le résultat serait, je pense catastrophique.
Enfin, un petit conseil:
Eloigne toi de ton ordinateurs quelques jours et surtout essaye de diminuer ta consommation de drogues.
[^] # Re: Execve dans sle noyau???
Posté par CoinKoin . Évalué à 2.
Je pense que, pour réaliser ce coup-là, il vaut mieux toucher au scheduler, de sorte que, lorsque le processus que tu veux voir exécuté en mode maître passe élu, le scheduler n'effectue pas le passage en mode esclave. Comme ça, tu n'auras qu'à lancer ton processus en mode esclave (où execve est valide), puis le passer en mode maître lors d'un changement de processus.
Cela-dit, sois conscient que cela constitue une évidente faille de sécurité, puisque cela permettrait potentiellement à n'importe qui d'exécuter un processus en mode protégé.
Ah, un détail encore : il faudra faire attention aux registres de segment lors du passage en mode maître, car leur valeur diffère selon le mode considéré (typiquement, le mode maître a accès à toute la mémoire).
Bon amusement avec l'assembleur!
# Oula...
Posté par TheBreton . Évalué à 2.
je voulais demander s'il est possible d'utiliser un appel system ( comme execve) dans un appel system que je veux ajouter dans un noyau linux . l'appel est du type:
En informatique tout est possible, il suffit de mettre le temps et la forme.
MAIS (il y en as toujours un) la methode que tu suis n'est pas la bonne, il faut revoir le pourquoi de fond pour t'indiquer le comment.
Qu'est ce que tu cherche a faire ?
Pour l'instant j'ai l'impression que tu melange allegrement les prog ecris pour tourner avec l'environnement user et ceux ecris pour le kernel (qui ont des regles d'ecriture distincte).
[^] # Re: Oula...
Posté par gadiri . Évalué à 1.
j'ai une fonction qui s'execute correctement en user space effectivement. Le but que je suis est d'implementer dans le noyau un mécanisme d'empechement d'envoi de message sur une file de messages IPC. Donc à la création d'une nouvelles file de messages, le noyau doit isoler deux numeros de processus du user courant. Chaque fois que un de ces deux processus voudra envoyer un msg sur cette file, le noyau va afficher un msg indiquant qu'il ne peut pas. Le programme qui est ci-dessous: liste les processus du user courant, en choisi deux aléatoirement et va écrire les numéros dans deux fichiers qui seront mappés en memoire en vu d'un partage futur avec d'autres processus. J'ai essayé d'integrer cela dans /ipc/msg.c comme fonction qui sera appelé dans la fonction msgget(). Mais j'ai plein d'erreurs. Les fonctions standard n'étant pas dispo dans le kernel space, pour gagner du temps j'avais pensé à execve.
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <time.h>
#include <sys/mman.h>
#include <sys/stat.h>
#define FILE_LENGTH 0x100
#define MAX_PID 32768
#define ID_UTILISATEUR 501
char s[100];
int v[10000];
struct stat buffer;
int i,k,t1,t2;//,stop1,stop2;
int stop1,stop2;
int j=0;
main()
{
int fd;
void* file_memory1,*file_memory2;
char* arg[2];
arg[0]= "/home/gadiri/test/stop1";
arg[1]= "/home/gadiri/test/stop2";
srand(time(NULL));
for(i=0;i<MAX_PID;i++)
{
sprintf(s,"/proc/%d",i);
if((stat(s,&buffer)!=-1) && (buffer.st_uid==ID_UTILISATEUR))
{
v[j]=i;
j++;
k=j;
}
}
t1=rand()%k;
t2=rand()%k;
stop1=v[t1];
stop2=v[t2];
printf("les processus interdits ont les numeros: v[%d]= %d et v[%d]= %d \n",t1,stop1,t2,stop2);
srand (time (NULL));
/* Prepare le fichier où on va stocker l'id du 1er proc interdit d'envoi de msg */
fd = open (arg[0], O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
lseek (fd, FILE_LENGTH+1, SEEK_SET);
write (fd, "", 1);
lseek (fd, 0, SEEK_SET);
/* mapping du fichier en memoire. */
file_memory1 = mmap (0, FILE_LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);
close (fd);
/* Ecriture du numero du processus en mémoire dans la zone du mapping. */
sprintf((char*) file_memory1, "%d\n", stop1);
/* Liberation de la mémoire. */
munmap (file_memory1, FILE_LENGTH);
/* Prepare le fichier où on va stocker l'id du 1er proc interdit d'envoi de msg */
fd = open (arg[1], O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
lseek (fd, FILE_LENGTH+1, SEEK_SET);
write (fd, "", 1);
lseek (fd, 0, SEEK_SET);
/* mapping du fichier en memoire. */
file_memory2 = mmap (0, FILE_LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);
close (fd);
/* Ecriture du numero du processus en mémoire dans la zone du mapping. */
sprintf((char*) file_memory2, "%d\n", stop2);
/* Liberation de la mémoire. */
munmap (file_memory2, FILE_LENGTH);
}
[^] # Re: Oula...
Posté par Pooly (site web personnel) . Évalué à 0.
tu le redirige vers un fichier a part, et tu met un daemon dessus qui poll le fichier...
[^] # Re: Oula...
Posté par CoinKoin . Évalué à 2.
Mais je te préviens qu'une solution de ce genre-là ne sera jamais acceptée par les mainteneurs du kernel, qui n'aiment pas que l'on s'écarte du modèle "noyau monolihique modulaire".
[^] # Re: Oula...
Posté par daggett . Évalué à 1.
- Pourquoi tu t'embetes à faire des mmap/munmap au lieu de simplement écrire dans le fichier ?? Remplace ton "int fd" par un "FILE *f", et remplace pour chaque id, tes 11 lignes de fd=open... à munmap par:
f = fopen (arg[0], "w");
fprintf(f, "%d\n", stop1);
fclose(f);
(Et je ne vois pas à quoi servait le lseek/write/lseek au début...)
[^] # Re: Oula...
Posté par daggett . Évalué à 1.
- "main()" c'est pas bien, "int main(int argc, char **argv)" c'est mieux :)
- Tu fais du copier-coller pour tes deux stop1 et stop2, c'est illisible et in-maintenable (par exemple dans les deux tu as laissé le meme commentaire "stocker l'id du 1er proc"... qui te dit que tu n'as pas laissé autre choses ?...), fais une fonction générale ecrire_id(int id, char *nom_fichier) que tu appeleras deux fois, ce sera plus simple...
- On verra les tailles en dur et les verifications d'erreur un autre jour :)
[^] # Re: Oula...
Posté par gadiri . Évalué à 1.
l'idée est de s'assurer que le fichier est assez grand pour contenir un entier non signé.
Remplace ton "int fd" par un "FILE *f"
qd j'ai fait cela j'ai eu des erreurs lors dela compilation du noyau. les fonctions de <stdio.h> ne sont pas reconnues.
les mmap et munmap ne sont pas indispensables.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.