David Decotigny a écrit 103 commentaires

Décidément, on va dire que je fais de la pub. Il me semble que la libreboîte te permet de spécifier quelques ports entrants. Ne l'utilisant pas en mode routeur routeur moi-même, c'est juste des souvenirs que j'ai apres avoir vu la page web d'admin très rapidement. Donc à confirmer.

Pour la libreboîte, ça peut faire du NAT si on veut, configurable a distance via le site web de Free. Voir la doc Freebox : http://adsl.free.fr/admin/routeur.html(...) ou section 2-5-2 du manuel dispo sur leur site.

Comme toolkits portables léger et relativement bien documentes il y a fltk effectivement. mais aussi fox. Pour ma part, j'utilise un peu fltk parce qu'il existe pas mal de widgets qui m'interessent (plots math, impression unix et windows). Dommage parce que Fox me parait beaucoup plus prorpre. Sinon il y a QT bien sûr, Je n'y ai jamais touché mais j'en ai entendu énormément de bien... ça reste à vérifier.

Je ne comprends pas bien : le programmeur a accès à la section "texte" quoi qu'il arrive (ou au "segment de code", ça dépend de la terminologie). Sous Unix il peut même la mettre en r/w si ça lui chante (cf exemple plus bas).

> ces processeurs n'ont aucune protection en écriture vis-à-vis des instructions exécutées en mode privilégié

Faux. c'est le bit WP du cr0 qui permet ça (a partir du 486).

Si le CPU ne dispose pas de MMU alors tout est permis (cf reponse qui cause de DSP). Si le CPU dispose d'une MMU alors il y a fort a parier qu'elle supporte la notion de droit hard (lecture/ecriture voire execution sur certaines archi) et/ou la notion de privilege (user/superviseur, voire plus de 2 niveaux). Par exemple sur IA32, la MMU est capable de gerer les droits lecture/ecriture et les niveaux de privilege (4 pour la segmentation, 2 pour la pagination). Les extensions plus recentes distinguent en plus un droit a l'execution (extension "NX" chez Intel, j'ai oublie le nom chez AMD).

Ce n'est pas le CPU qui etablit tout seul a quel endroit qui a le droit d'ecrire/lire/executer. C'est l'OS. Donc a son tour l'OS peut decider d'exploiter ces notions ou pas. Par exemple DOS ne gere rien de tout ça ; le DOS de base ne sait meme pas qu'il y a une MMU. Mais Windows et les Unix exploitent ces notions.

C'est donc une combinaison hard/soft qui decide quoi faire au niveau des privileges et des droits d'acces autorises. C'est "politique" tout ça, l'OS peut faire ce qu'il veut.

En general (cas Linux/Windows), l'OS considere que les applis utilisateur sont executees avec le plus bas privilege. Ca interdit a ces applications l'utilisation de certaines instructions dont celles qui pourraient modifier leur config de la MMU ou leur niveau de privilege (mise a part les syscalls). Au niveau des privileges, donc, l'appli ne peut rien changer. Sauf si l'OS lui autorise a le faire (jamais le cas sous Linux).

Ensuite, les droits d'acces (r/w voire x) en VM sont definis aussi par l'OS. Mais pas n'importe comment. Dans le cas courant (Unix/Windows) ces droits sont definis dans le format de l'executable qui est charge (man objdump + comparer avec /proc/pid/maps). C'est le compilo qui genere ces fichiers, c'est lui qui dit quelle zone est r/w/x. Par defaut, les sections de code sont en rx, les sections data (et bss) en rw et les sections "rodata" (chaines de caracteres ecrites en dur dans le source) en read-only. Tout acces non autorise generera un SEGV.

Cependant, sous Unix (et j'imagine aussi sous windows), l'appli a toute lattitude pour modifier ces droits. Ca peut se faire en amont lors de la compilation (p.ex : demander a gcc de mettre les chaines en data plutot que rodata) et/ou de l'edition de liens (modif des scripts ld). Ca peut se faire aussi a l'execution (mprotect) car l'OS propose des syscalls pour que l'appli puisse modifier ses droits d'acces (syscalls nécessaires pour ld.so). Par exemple, le programme suivant passera une partie du code en r/w et ecrasera le debut du code de la fonction f (SEGV assure):

-----------------------------------------------------
#include <stdio.h>
#include <sys/mman.h>
#include <string.h>

void f()
{
printf("Hugh\n");
}


int main ()
{
int * ptr_f = (int*)f;
printf("Salut\n");
mprotect(((void*) (((long)ptr_f) & ~4095)), 4096,
PROT_READ | PROT_WRITE | PROT_EXEC);
*ptr_f = 0xdeadbeef;
f();
return 0;
}
-----------------------------------------------------

Evidemment, si on vire le mprotect on aura aussi un SEGV mais pas pour les memes raisons. Dans le premier cas (avec mprotect) c'est le code de f qui a ete ecrase et donc qui fait n'imorte quoi (=> SEGV), dans le 2eme cas (sans mprotect) c'est que main tente d'ecrire sur une zone en lecture seule.

Sinon, l'injection de code ne correspond pas obligatoirement a la creation d'un thread parasite. Il sagit tout betement d'ecrire du code la ou on peut sans grand effort (p.ex sur la pile par debordement de tableau local), puis a ruser la pile pour dire au CPU de sauter a l'endroit ou le code a ete injecte. Apres le code injecte peut faire ce qu'il veut : pourquoi pas creer un thread si ca lui chante.

Pour les perfs, je n'en ai aucune idée.

Pour ma part, l'intérêt est de s'amuser avec le CPU 64 bits pour pas trop cher. Les 95% du temps mon CPU pédale à 1GHz et ça me suffit (très) largement.

Je retire ce que j'ai dit : forcedeth et sata_nv ont l'air d'être bel et bien compilés dans le noyau de netinst. Il semblerait que netinst oublie bêtement de les charger... ou ne sait qu'il faut au moins essayer de les charger.

Benjamin, pourrais-tu essayer ce que Nicolas propose et nous dire si ça marche ? Genre tu bootes la netinst et, une fois le premier écran de questions apparu, tu vas sur une autre console et tu tapes les 2 lignes de modprobe que Nicolas a données...

Malheureusement forcedeth n'est pas compilé dans le noyau de la netinst. Pour ma part, j'ai du utiliser une autre carte réseau le temps de l'installation. Une fois un nouveau noyau compilé, ça marche.

Pour le sata, j'imagine que c'est la même chose. Je suis encore en p-ata donc je n'ai pas pu tester tout ça. Une solution est peut-être de passer par une ubuntu amd64 car j'imagine que tout ça est supporté de base, puis d'installer la sarge amd64 en chroot (https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howt(...) Faut reconnaître, c'est pas super évident, il faudrait que quelqu'un se dévoue pour documenter ça.

Pareil pour moi (Asus A8N-E) : ça marche vraiment bien.

En effet. Tous les fichiers pour tout configurer (X et console) sont sur linux-france :
http://www.linux-france.org/macintosh/clavier_v4.html(...)
Le mapping des touches est détaillé et est le meme sous X et en console :
ftp://ftp.linux-france.org/pub/macintosh/kbd-mac-map.txt(...)

Toutes les manips sont expliquees dans (entre autres) cette doc :
http://david.decotigny.free.fr/wiki/wakka.php?wiki=SargeIBook2(...)
qui est une version remise a jour recemment de
http://david.decotigny.free.fr/libre/ibook2-debian/(...)

C'est peut-etre moins courant que sur Ethernet, mais IP sur 1394 ça marche bien aussi.

Non, le -lpthread ne suffit pas. Il faut, dès l'étape de compilation, rajouter le define _REENTRANT (ie passer -D_REENTRANT à gcc). C'est de première importance pour (entre autres) "errno" (variable partagée sans le define, macro utilisant une variable __thread ou un appel à un truc genre pthread_getspecific avec le define).

Toutes fonctions marquées "MT-safe" dans le man deviendront réentrantes. Il y a des exceptions (gethostbyname, gethostent, etc...) mais elles ont leur equivalent reentrant (suffixe "_r"). RTFM.

Donc printf deviendra reentrant, au sens ou si tu veux afficher "abcd", tu auras toujours 'a' 'b' 'c' 'd' affiches dans cet ordre et sans risque de bug aleatoire. Mais aucune synchro n'est prise pour que 2 printf ne s'entrelacent pas. Ce qui veut dire qu'un printf("abcd") peut tres bien s'entrelacer avec un printf("efgh").

S'il s'agit de controler les 3 registres du port //, sous Linux aucun besoin d'attaquer le bus I/O (ioperm, inb, outb), c'est meme a eviter. Pour les methodes plus traditionnelles, cf le lien que rappelle Robin des bulles (ppdev). S'il s'agit d'imprimer des trucs sur une imprimante parallele, il suffit de faire des read et des write sur /dev/lpX.

Et puis, franchement, les docs sur le port // pour Linux et Windows, c'est pas ca qui manque sur google.

http://people.redhat.com/twaugh/parport/html/ppdev.html(...)
http://www.torque.net/linux-pp.html(...)
http://www.lvr.com/parport.htm(...)

J'ai vu plusieurs propositions pour utiliser les ioperm et inb/outb directement. NON. Sous Linux il y a le module "ppdev" qui gere le "device" /dev/parport0 (pour LPT1), /dev/parport2, etc...

Exemple de prog de test pour controler le registre de donnees :

static int init_parport()
{
int fd_pp, i;

fd_pp = open("/dev/parport0", O_WRONLY);
if (fd_pp < 0)
{
perror("open lp");
return 0;
}

ioctl(fd_pp, PPCLAIM);
i = PARPORT_MODE_COMPAT;
ioctl(fd_pp, PPSETMODE, & i);
i = IEEE1284_MODE_COMPAT;
ioctl(fd_pp, PPNEGOT, & i);

return fd_pp;
}


void send_parport(int fd_pp, unsigned char data)
{
ioctl(fd_pp, PPWDATA, & data);
}

/* Et pour relacher le port :
unsigned char data;

data = 0;
ioctl(parport_fd, PPWDATA, & data);
ioctl(parport_fd, PPRELEASE);

return close(parport_fd);
*/

Evidemment, cet exemple est facilement adaptable pour controler les 2 autres registres (remplacer DATA par STATUS et CONTROL). Pour modifier ce source, voir l'API definie dans ppdev.h de include/linux/ . Dans le source, on utilise le mode de base du port // : tous les autres modes sont dispo (en particupier EPP).

Sous windows, j'ai pas trouve mieux que d'utiliser inpout32.dll qui permet de se ramener au niveau inb/outb a la main. Peut-etre qu'une ecriture toute bete sur le "fichier" "LPT1" suffit.

J'ai juste oublie de preciser que le source fourni s'appelle "unembed.c"...

Exemple de manip:
On veut caser toute un tar.gz dans un executable, le decompresser a la volee dans un repertoire temporaire, et executer le programme nommé "run" contenu dans cette archive.

Pour ca, on commence a fabriquer son tar.gz avec son executable "run" a faire demarrer une fois que la decompression sera faite : binaire ou script shell. Ensuite on fabrique un .o qui contient cette archive dans la section .rodata, et on repere les donnees ainsi enfouies par les symboles "__embed" et "_e_embed". Enfin, on lie ce .o avec un autre .o qui contient le code de decompression.

Bon, finalement c'est peut-etre plus simple avec le code sous les yeux.

- Le fichier qui decompresse l'archive integree dans le binaire et qui lance le programme "run" de cette archive :

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

extern char _b_embed, _e_embed;

int main ()
{
FILE * pipe;
char dirname[] = "/tmp/.embedXXXXXX";
char * contents;

mkdtemp(dirname);
if (! dirname)
return -1;

if (chdir(dirname))
return -1;

pipe = popen("tar xzf -", "w");
if (! pipe)
return -1;

for (contents = & _b_embed ; contents < & _e_embed ; contents ++)
{
if (fwrite(contents, 1, 1, pipe) != 1)
return -1;
}

if (pclose(pipe))
return -1;

execl("./run", "./run", NULL);

return -1;
}

- Le Makefile qui fait l'archive a compresser avec le fichier run (un script de base) a demarrer une fois que tout sera decompresse. On en profite pour mettre d'autres trucs bidon dans l'archive. Au final, le make construit le binaire avec l'archive enfouie :

all: demo

demo: unembed.o embedded_archive.o
$(CC) -o $@ unembed.o embedded_archive.o

embedded_archive.o: archive.tgz
touch container.c && $(CC) -c container.c
objcopy --add-section .embed=$< container.o
echo "SECTIONS { .rodata . : { _b_embed = .; container.o(.embed); _e_embed = .; }}" \
> script.lds
ld -r -o $@ script.lds

archive.tgz:
echo "#! /bin/sh" > run
echo 'echo "######### Hello World ! #########"' >> run
echo 'echo Cur dir=`pwd`' >> run
echo "echo Dir contents:" >> run
echo "ls -la" >> run
# echo "make && ./demo" >> run
chmod 755 run
tar czf $@ run Makefile unembed.c

clean:
$(RM) unembed.o* demo archive.tgz embedded_archive.o

Et voila ! Maintenant je mets l'executable "demo" n'importe ou, je l'execute, et, dans le /tmp/.embedXYZTUV, ce decompressera tout et ca lancera le script "run" !

Note : le "XYZTUV" est genere par mkdtemp, le script "run" s'occupera de l'afficher.

Note 2 : le code a l'air de marcher, il y a peut-etre quelques optimisations a faire (regarder du cote de fwrite).

Et pourquoi ne pas faire la chose suivante :

Dans le prog final :
- Une section elf ".embedded_prog" avec des symboles _b_embed et _e_embed pour la localiser
- Dans cette section, le binaire du programme a charger /decompresser
- Le programme de chargement decompression

Le programme de chargemement/decompression faisant les choses suivantes :
- ecriture des donnees entre les symboles _b_embed et _e_embed dans un fichier temporaire (decompression a la volee ou a posteriori)
- fork() puis exec() du fichier temporaire

Et voila ! Pour ce qui est de comment inclure un fichier dans une section, man objcopy ou voir SOS dans le linux magazine de Mars dernier (tiens ca me fait penser que le code de n'est pas encore en ligne).

fabb, dans un noyau il n'y a pas qu'1 API destinee aux drivers. Il y en a pour tous les sous-systemes, qui sont eux-memes utilises par les autres sous-systemes, utilises par les autres sous-systemes, etc... utilises par les drivers, utilises par d'autres sous-systemes, etc... utilises par les applications utilisateur.

Bref, une API noyau n'est pas forcement utilisee par les drivers directement. C'est pas pour ca qu'on doit dire "boarf, c'est de la cuisine interne au noyau, c'est forcement bas niveau, donc ca depend du matos et le noyau se debrouille.". Non. Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise. Parce qu'une contrainte des noyaux du genre Linux, c'est qu'il doit etre "portable", ie adaptable a plusieurs archi en touchant le moins de code possible. Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi. Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?

Bon, j'espere que jusqu'ici c'est clair. Maintenant qu'on a dit qu'une API de gestion de la MMU etait necessaire (bien que peu de drivers l'utilisent directement), la question se pose de la definir. Dans Linux, l'histoire a choisi une API a base de tables simples avec 2 ou 3 indirections (resp 3 ou 4 niveaux de tables). Eh bien je ne suis pas convaincu que ce soit le meilleur choix. D'une part parce que cette API est un gouffre en termes de perf quand l'archi ne repose pas sur un systeme a indirection simple parce que emuler en soft ce systeme peut etre tres complexe quand on ne dispose pas en hard des elements en question (ex : ppc repose sur une serie de tables de hachage, pas facile d'emuler des tables a indirection a partir de ca). D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.

Pour Brice : vivement Jeudi que je lise cet article lwn ! Si ca continue je m'abonne.

Maintenant UML est intégré directement dans les noyaux 2.6 "standard".

make menuconfig ARCH=um
make linux ARCH=um

(mais qui es-tu "borntoulouse" ? Tes initiales seraient-elles L.C. ? Ou R.J. ?)

Chouette, un troll pour techos !

>> c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique

Linux ne se voulait pas portable a ses debuts, c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.

> Oui mais c'est impossible.

Oh, allez, ne soyons pas defaitiste comme ça ! Allons, reprenons-nous ;)

> Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.

Donc ca voudrait dire que les drivers devraient se contrefoutre de ces histoires de X niveaux d'indirection. Ce qui veut dire que si on a une API de gestion de la MMU qui ne rend pas publique ces histoires de X niveaux d'uindirections, alors les drivers ne se porteront pas plus mal. Bref, cette remarque va dans le sens de ce qui suit...

> Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.

Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc.. et bien sûr c'est cette couche qui s'occupe de fournir le necessaire a la MMU (tables de traduction directes, de hachage, etc...).

En effet, c'est un patch qui change pas mal quelques algorithmes.

N'empeche il serait temps que linux definisse une API de gestion de la VM qui se detache un peu des details de la MMU du x86. C'est pas pour dire, mais sur d'autres archi, la MMU ne travaille pas du tout avec des tables de traduction "directes" comme dans le cas x86 (je pense a ppc). Mieux vaudrait avoir une API bien plus propre, bien plus simple et bien plus portable que celle qui consiste a emuler les X niveaux d'indirection de la MMU x86.

Voila, c'etait mes 3 cents de mauvaise humeur... Troll en perspective ?

Il y en a au moins 2 autres utilisées dans le monde de la physique :
- Scientific Linux (Fermilab) : https://www.scientificlinux.org/(...)
- Scientific Linux CERN : http://linux.web.cern.ch/linux/scientific3/(...)
SLC est en fait une "saveur" (flavour) CERN de la SL de Fermilab.

Je confirme, l'ibook 800 (ils viennent de sortir une nouvelle version a 900MHz, peut-etre que ca change des choses) est maintenant tres bien supporte : video 2d/3d, son, ethernet 10/100, mode veille, mode basse consommation, clavier, trackpad, cd/graveur, souris sur usb, et meme modem interne, ou modem free sur usb ! A noter aussi que la debian unstable marche putot bien, aussi bien que sur pc en ce qui concerne mon utilisation courante (pas de jeux). En tous cas, S.K., merci pour la pub ;)

> T'as pas fait avec les paquets de ronland mas? (http://roland.mas.free.fr/(...) )

Non, a la main, c'est tellement facile...

> Sinon, t'as testé sur le ibook avec la knoppix-MiB PPC ?

Non plus, faudra que j'essaye ca, pour voir...

Et sinon, pour mes histoires de GPL, j'ai tout faux ?