Discutant avec un camarade GNU/Linuxien, et le sujet abordant la
portabilité, je n'ai pas su quoi lui répondre quand nous avons constaté
qu'il n'existait pas de port NetBSD pour les Palm.
Pourtant, le DragonBall est à base de 68K, qui est une architecture bien
maîtrisée par les développeurs NetBSD.
C'est parce que les NetBSDistes (?) n'ont pas eu de Palm III ?
(je ne connais pas les nouveaux Zire et machins...)
Si, à bidouiller dans le train. Un portable c'est trop lourd et encombrant.
C'est bien pour ça qu'il faut voyager avec un ou deux bouquins, c'est tellement plus agréable !
Et puis on peut faire plein de trucs avec un PDA, comme planifier les rendez-vous et activités que l'on ne pourra bien sûr pas assumer.
Et ensuite perdre ledit PDA, ou se le faire faucher, ou être victime d'une malencontreuse panne matérielle. Alors ça c'est pas de chance !
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place. Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des traces de la console...
Si, à bidouiller dans le train. Un portable c'est trop lourd et encombrant.
C'est bien pour ça qu'il faut voyager avec un ou deux bouquins, c'est
tellement plus agréable !
Et puis on peut faire plein de trucs avec un PDA, comme planifier les
rendez-vous et activités que l'on ne pourra bien sûr pas assumer.
Et ensuite perdre ledit PDA, ou se le faire faucher, ou être victime
d'une malencontreuse panne matérielle. Alors ça c'est pas de chance !
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post
plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place.
Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des
traces de la console...
Si, à bidouiller dans le train. Un portable c'est trop lourd et encombrant.
C'est bien pour ça qu'il faut voyager avec un ou deux bouquins, c'est tellement plus agréable !
Et puis on peut faire plein de trucs avec un PDA, comme planifier les rendez-vous et activités que l'on ne pourra bien sûr pas assumer.
Et ensuite perdre ledit PDA, ou se le faire faucher, ou être victime d'une malencontreuse panne matérielle. Alors ça c'est pas de chance !
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place. Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des traces de la console...
gregg
Miod Vallat wrote:
Non, le MMU sert à pouvoir accéder à la mémoire physique autrement qu'avec une correspondance 1:1.
Correspondance page virtuelle <-> cadre de page physique, nous sommes d'accord.
Pour ce faire, il est indispensable qu'il fournisse un minimum de protection (au moins pour les accès en lecture et en écriture).
Pourquoi ? (ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Faire correspondre une adresse virtuelle 4 d'un processus A avec un cadre de page physique 12, et une adresse virtuelle 4 d'un processus B avec un cadre de page physique 76: en quoi la protection mémoire est-elle nécessaire (il ne faut qu'un couple (id_processus, adresse_virtuelle) pour retrouver le cadre de page correspondant dans la table des pages.) (je pense à une table classique, pas inversée).
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la MMU cette fois) ?
Je ne suis pas sûr de comprendre ce que tu veux dire...
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ma connaissance des b.o. est plutôt limitée à vrai dire (en ce sens que je n'ai jamais essayé: du coup j'ai un TP à faire pour ce soir alors ? :-)
Bref. J'avais cette idée: la MMU est conçue pour la pagination (pas la segmentation, qui est elle gérée par le système, donc logicielle).
Parce que si on estime que le but de la MMU est de protéger la mémoire, alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à déborder les tampons (notamment).
D'un autre côté, j'ai appris la MMU avec Tanenbaum ("Systèmes d'exploitation", 2e éd., je crois que c'est le chapitre 4): c'est l'idée que m'en a laissé le bouquin, mais ce n'est peut-être pas le meilleur pour "capter" l'essence de la MMU.
Ou alors, c'est qu'on ne s'entend pas sur le terme de "protection mémoire" (vu qu'il est employé à tord et à travers, surtout quand on lit les forums Amiga). Bref. Protection mémoire: contre les accès lecture/écriture d'un processus donné ? Ou protection dans le sens de cloisonnement (protéger les accès des processus concurrents à une page mémoire donnée) ?
Je crois l'avoir entendu dans le second, alors que tu pensais au premier, non ?
Ça doit dépendre du modèle. De toutes façons, le pain est nettement meilleur grillé au four.
Euh, moi je le préfère grillé au five.
Hum. Désolé.
++
Miod Vallat wrote:
Non, le MMU sert à pouvoir accéder à la mémoire physique autrement
qu'avec une correspondance 1:1.
Correspondance page virtuelle <-> cadre de page physique, nous sommes
d'accord.
Pour ce faire, il est indispensable qu'il fournisse un minimum de
protection (au moins pour les accès en lecture et en écriture).
Pourquoi ?
(ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Faire correspondre une adresse virtuelle 4 d'un processus A avec un
cadre de page physique 12, et une adresse virtuelle 4 d'un processus B
avec un cadre de page physique 76: en quoi la protection mémoire
est-elle nécessaire (il ne faut qu'un couple (id_processus,
adresse_virtuelle) pour retrouver le cadre de page correspondant dans la
table des pages.) (je pense à une table classique, pas inversée).
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce
n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la
MMU cette fois) ?
Je ne suis pas sûr de comprendre ce que tu veux dire...
Je pensais que le buffer overflow était lié à la segmentation de la
mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow
sur la pile, était de déborder du segment de pile pour atteindre le tas,
par exemple. Voire plus (ça dépend de combien on peut faire remonter)
(ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ma connaissance des b.o. est plutôt limitée à vrai dire (en ce sens que
je n'ai jamais essayé: du coup j'ai un TP à faire pour ce soir alors ? :-)
Bref. J'avais cette idée: la MMU est conçue pour la pagination (pas la
segmentation, qui est elle gérée par le système, donc logicielle).
Parce que si on estime que le but de la MMU est de protéger la mémoire,
alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à
déborder les tampons (notamment).
D'un autre côté, j'ai appris la MMU avec Tanenbaum ("Systèmes
d'exploitation", 2e éd., je crois que c'est le chapitre 4): c'est l'idée
que m'en a laissé le bouquin, mais ce n'est peut-être pas le meilleur
pour "capter" l'essence de la MMU.
Ou alors, c'est qu'on ne s'entend pas sur le terme de "protection
mémoire" (vu qu'il est employé à tord et à travers, surtout quand on lit
les forums Amiga).
Bref. Protection mémoire: contre les accès lecture/écriture d'un
processus donné ?
Ou protection dans le sens de cloisonnement (protéger les accès des
processus concurrents à une page mémoire donnée) ?
Je crois l'avoir entendu dans le second, alors que tu pensais au
premier, non ?
Ça doit dépendre du modèle. De toutes façons, le pain est nettement
meilleur grillé au four.
Non, le MMU sert à pouvoir accéder à la mémoire physique autrement qu'avec une correspondance 1:1.
Correspondance page virtuelle <-> cadre de page physique, nous sommes d'accord.
Pour ce faire, il est indispensable qu'il fournisse un minimum de protection (au moins pour les accès en lecture et en écriture).
Pourquoi ? (ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Faire correspondre une adresse virtuelle 4 d'un processus A avec un cadre de page physique 12, et une adresse virtuelle 4 d'un processus B avec un cadre de page physique 76: en quoi la protection mémoire est-elle nécessaire (il ne faut qu'un couple (id_processus, adresse_virtuelle) pour retrouver le cadre de page correspondant dans la table des pages.) (je pense à une table classique, pas inversée).
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la MMU cette fois) ?
Je ne suis pas sûr de comprendre ce que tu veux dire...
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ma connaissance des b.o. est plutôt limitée à vrai dire (en ce sens que je n'ai jamais essayé: du coup j'ai un TP à faire pour ce soir alors ? :-)
Bref. J'avais cette idée: la MMU est conçue pour la pagination (pas la segmentation, qui est elle gérée par le système, donc logicielle).
Parce que si on estime que le but de la MMU est de protéger la mémoire, alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à déborder les tampons (notamment).
D'un autre côté, j'ai appris la MMU avec Tanenbaum ("Systèmes d'exploitation", 2e éd., je crois que c'est le chapitre 4): c'est l'idée que m'en a laissé le bouquin, mais ce n'est peut-être pas le meilleur pour "capter" l'essence de la MMU.
Ou alors, c'est qu'on ne s'entend pas sur le terme de "protection mémoire" (vu qu'il est employé à tord et à travers, surtout quand on lit les forums Amiga). Bref. Protection mémoire: contre les accès lecture/écriture d'un processus donné ? Ou protection dans le sens de cloisonnement (protéger les accès des processus concurrents à une page mémoire donnée) ?
Je crois l'avoir entendu dans le second, alors que tu pensais au premier, non ?
Ça doit dépendre du modèle. De toutes façons, le pain est nettement meilleur grillé au four.
Euh, moi je le préfère grillé au five.
Hum. Désolé.
++
Miod Vallat
Pour ce faire, il est indispensable qu'il fournisse un minimum de protection (au moins pour les accès en lecture et en écriture).
Pourquoi ? (ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Parce que, à partir du moment où il y a une indirection dans le calcul des adresses, il est possible (et fréquent) d'avoir des trous dans l'espace d'adressage, i.e. une adresse virtuelle à laquelle n'est associée aucune adresse physique.
Du coup, il faut bien pouvoir réagir lorsque ton programme va naïvement essayer d'accéder à ces adresses qui pointent dans le vide.
D'autre part, les structures de données du MMU sont très fréquemment elles-même dans la mémoire accessible au processeur, pour des raisons d'efficacité et de simplicité de conception ; il n'y a que les registres de contrôle du MMU qui soient à part (et encore, certains MMU ont les registres eux-mêmes accessibles uniquement en tant que mémoire du processeur).
Afin d'éviter d'aller au devant de graves ennuis lorsqu'une application mal programmée va écrire n'importe quoi en mémoire, il est nécessaire que la mémoire du MMU ne soit pas accessible en écriture à tout moment... Donc des critères de protection des accès mémoire deviennent nécessaire (accès en lecture, en écriture, en exécution, depuis le mode superviseur, depuis un ASI particulier, etc - tous les MMU ne fournissent pas autant de flexibilité).
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ça c'est une forme particulière d'oflow. Connaître la forme générale de l'espace d'adressage du processus à exploiter aide indéniablement.
Parce que si on estime que le but de la MMU est de protéger la mémoire, alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à déborder les tampons (notamment).
Le MMU travaille sur des pages. C'est une granularité bien trop grosse pour la problématique des oflows. La protection ici est principalement entre les processus/ASI, d'une part, et entre les modes utilisateur/superviseur, d'autre part.
Pour ce faire, il est indispensable qu'il fournisse un minimum de
protection (au moins pour les accès en lecture et en écriture).
Pourquoi ?
(ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Parce que, à partir du moment où il y a une indirection dans le calcul
des adresses, il est possible (et fréquent) d'avoir des trous dans
l'espace d'adressage, i.e. une adresse virtuelle à laquelle n'est
associée aucune adresse physique.
Du coup, il faut bien pouvoir réagir lorsque ton programme va naïvement
essayer d'accéder à ces adresses qui pointent dans le vide.
D'autre part, les structures de données du MMU sont très fréquemment
elles-même dans la mémoire accessible au processeur, pour des raisons
d'efficacité et de simplicité de conception ; il n'y a que les registres
de contrôle du MMU qui soient à part (et encore, certains MMU ont les
registres eux-mêmes accessibles uniquement en tant que mémoire du
processeur).
Afin d'éviter d'aller au devant de graves ennuis lorsqu'une application
mal programmée va écrire n'importe quoi en mémoire, il est nécessaire
que la mémoire du MMU ne soit pas accessible en écriture à tout
moment... Donc des critères de protection des accès mémoire deviennent
nécessaire (accès en lecture, en écriture, en exécution, depuis le mode
superviseur, depuis un ASI particulier, etc - tous les MMU ne
fournissent pas autant de flexibilité).
Je pensais que le buffer overflow était lié à la segmentation de la
mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow
sur la pile, était de déborder du segment de pile pour atteindre le tas,
par exemple. Voire plus (ça dépend de combien on peut faire remonter)
(ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ça c'est une forme particulière d'oflow. Connaître la forme générale de
l'espace d'adressage du processus à exploiter aide indéniablement.
Parce que si on estime que le but de la MMU est de protéger la mémoire,
alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à
déborder les tampons (notamment).
Le MMU travaille sur des pages. C'est une granularité bien trop grosse
pour la problématique des oflows. La protection ici est principalement
entre les processus/ASI, d'une part, et entre les modes
utilisateur/superviseur, d'autre part.
Pour ce faire, il est indispensable qu'il fournisse un minimum de protection (au moins pour les accès en lecture et en écriture).
Pourquoi ? (ou alors je ne comprends pas très bien, ce qui est plus que probable :-)
Parce que, à partir du moment où il y a une indirection dans le calcul des adresses, il est possible (et fréquent) d'avoir des trous dans l'espace d'adressage, i.e. une adresse virtuelle à laquelle n'est associée aucune adresse physique.
Du coup, il faut bien pouvoir réagir lorsque ton programme va naïvement essayer d'accéder à ces adresses qui pointent dans le vide.
D'autre part, les structures de données du MMU sont très fréquemment elles-même dans la mémoire accessible au processeur, pour des raisons d'efficacité et de simplicité de conception ; il n'y a que les registres de contrôle du MMU qui soient à part (et encore, certains MMU ont les registres eux-mêmes accessibles uniquement en tant que mémoire du processeur).
Afin d'éviter d'aller au devant de graves ennuis lorsqu'une application mal programmée va écrire n'importe quoi en mémoire, il est nécessaire que la mémoire du MMU ne soit pas accessible en écriture à tout moment... Donc des critères de protection des accès mémoire deviennent nécessaire (accès en lecture, en écriture, en exécution, depuis le mode superviseur, depuis un ASI particulier, etc - tous les MMU ne fournissent pas autant de flexibilité).
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Ça c'est une forme particulière d'oflow. Connaître la forme générale de l'espace d'adressage du processus à exploiter aide indéniablement.
Parce que si on estime que le but de la MMU est de protéger la mémoire, alors, depuis le temps, elle fait mal son boulot, puisqu'on arrive à déborder les tampons (notamment).
Le MMU travaille sur des pages. C'est une granularité bien trop grosse pour la problématique des oflows. La protection ici est principalement entre les processus/ASI, d'une part, et entre les modes utilisateur/superviseur, d'autre part.
manu
Miod Vallat wrote:
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place. Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des traces de la console...
Le jornada peut enregistrer des traces, et en plus il peut prendre une interface ethernet en PCMCIA. C'est un très bon outil de diagnostic, bien moins encombrant qu'un portable ou qu'une VT, et avec une durée de batterie inégallée.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Miod Vallat <miod@online.fr> wrote:
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post
plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place.
Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des
traces de la console...
Le jornada peut enregistrer des traces, et en plus il peut prendre une
interface ethernet en PCMCIA. C'est un très bon outil de diagnostic,
bien moins encombrant qu'un portable ou qu'une VT, et avec une durée de
batterie inégallée.
Et ça sert de console, aussi (comme le dit Emmanuel Dreyfus dans un post plus tôt). C'est bien pratique des fois.
Moi j'utilise des VT où, a défaut, les machines disponibles sur place. Pas besoin d'utiliseur un jouet. Et puis comme ça je peux conserver des traces de la console...
Le jornada peut enregistrer des traces, et en plus il peut prendre une interface ethernet en PCMCIA. C'est un très bon outil de diagnostic, bien moins encombrant qu'un portable ou qu'une VT, et avec une durée de batterie inégallée.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
manu
Miod Vallat wrote:
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la MMU cette fois) ? Je ne suis pas sûr de comprendre ce que tu veux dire...
<aol>Moi non plus</aol>
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Miod Vallat <miod@online.fr> wrote:
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce
n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la
MMU cette fois) ?
Je ne suis pas sûr de comprendre ce que tu veux dire...
<aol>Moi non plus</aol>
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
D'un autre côté, le buffer overflow existe malgré la MMU: est-ce que ce n'est pas plutôt dû à la segmentation (qui est logicielle, pas liée à la MMU cette fois) ? Je ne suis pas sûr de comprendre ce que tu veux dire...
<aol>Moi non plus</aol>
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu
gregg wrote:
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Il y a des pages non mappées entre la pile et le tas, donc on plante avant de déborder de l'un à l'autre. Si la pile et le tas étaient connexes, alors on ne pourrait pas les agrandir, ce qui serait assez ennuyeux.
Les buffer overflow ont plutot tendance à écraser les données voisines du buffer débordant pour y placer du code.
Je pensais que le buffer overflow était lié à la segmentation de la
mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow
sur la pile, était de déborder du segment de pile pour atteindre le tas,
par exemple. Voire plus (ça dépend de combien on peut faire remonter)
(ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Il y a des pages non mappées entre la pile et le tas, donc on plante
avant de déborder de l'un à l'autre. Si la pile et le tas étaient
connexes, alors on ne pourrait pas les agrandir, ce qui serait assez
ennuyeux.
Les buffer overflow ont plutot tendance à écraser les données voisines
du buffer débordant pour y placer du code.
Je pensais que le buffer overflow était lié à la segmentation de la mémoire, et non à sa pagination. Autrement dit, que le but de l'overflow sur la pile, était de déborder du segment de pile pour atteindre le tas, par exemple. Voire plus (ça dépend de combien on peut faire remonter) (ou plutôt descendre, ça dépend de l'architecture et de la gestion de pile).
Il y a des pages non mappées entre la pile et le tas, donc on plante avant de déborder de l'un à l'autre. Si la pile et le tas étaient connexes, alors on ne pourrait pas les agrandir, ce qui serait assez ennuyeux.
Les buffer overflow ont plutot tendance à écraser les données voisines du buffer débordant pour y placer du code.
