Module NSA encryption spek inclus =c3=a0 partir du Kernel 4=2e17 =3a C'est quoi =3f Il sert =c3=a0 quoi =3f
22 réponses
Pierre www.zetrader.fr
Hello, au hasard de mes recherches, j'apprends l'existence d'un module
NSA qui serait intégré depuis le kernel 4.17, et je m'interroge sur son
rôle :
https://www.omgubuntu.co.uk/2018/08/linux-4-18-kernel-release-features
Un gars demande en com "Was NSA code removed from Linux kernel in this
new version?"
Et rajoute dans la conversation :
"I know Linux is open source, I've been using it as my main O.S. (the
only one installed in my computer) since 2006 and I know I can put the
NSA module in a blacklist and that's all, but what paid my attention
here is the way It was included in the kernel. My understanding is that
Google did some pressure to include it, even considering that Speck
algorithm was rejected by ISO, so my little worry here is more political
than technical."
En cherchant dans google, je vois que certains veulent le retirer :
https://askubuntu.com/questions/1067399/remove-nsa-encryption-speck
"The file speck.ko can be found in
/lib/modules/4.18.1-041801-generic/kernel/crypto and it was built by the
NSA (added since Linux Kernel 4.17). I really want to remove this thing
from my computer. "
Donc ma question : il me sert à quoi ce module NSA encryption spek ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 2018-12-02, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pu12dm$5cf$) :
Doug713705 wrote:
Je ne suis pas certain que ce soit systématique. Chaque option semble avoir un un comportement qui lui est propre.
Juste, (pour dmesg).
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Une raison possible est expliquée ici: https://lists.debian.org/debian-kernel/2004/10/msg00023.html C'est du gaspillage, alors que si le système est géré par Debian, /boot/{config,vmlinuz,initrd}-$(uname -r) contient l'information nécessaire.
Mais cela ne garanti pas que le noyau n'a pas été altéré. L'économie de ~200 Ko de RAM me semble être une excuse fallacieuse et, si on va par là, le "gaspillage" est tout aussi avéré sur le disque. Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système. -- Chez les vieilles qui trafiquent le spleen, T'as bouffé tes nerfs et tes nuits Et maintenant tu cherches une combine Pour domestiquer nos envies. -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 2018-12-02, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration
(<pu12dm$5cf$1@shakotay.alphanet.ch>) :
Doug713705 <doug.letough@free.fr> wrote:
Je ne suis pas certain que ce soit systématique.
Chaque option semble avoir un un comportement qui lui est propre.
Juste, (pour dmesg).
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé
par Debian (et bien d'autres). Cela permet de vérifier la configuration
du noyau en cours d'utilisation quand un fichier dans /boot ne garanti
pas qu'il correspond au noyau en cours.
C'est du gaspillage, alors que si le système est géré par Debian,
/boot/{config,vmlinuz,initrd}-$(uname -r) contient l'information
nécessaire.
Mais cela ne garanti pas que le noyau n'a pas été altéré.
L'économie de ~200 Ko de RAM me semble être une excuse fallacieuse
et, si on va par là, le "gaspillage" est tout aussi avéré sur le disque.
Desactiver cette option sur des systèmes embarqués disposant de peu de
RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur
ce genre de système.
--
Chez les vieilles qui trafiquent le spleen,
T'as bouffé tes nerfs et tes nuits
Et maintenant tu cherches une combine
Pour domestiquer nos envies.
-- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 2018-12-02, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pu12dm$5cf$) :
Doug713705 wrote:
Je ne suis pas certain que ce soit systématique. Chaque option semble avoir un un comportement qui lui est propre.
Juste, (pour dmesg).
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Une raison possible est expliquée ici: https://lists.debian.org/debian-kernel/2004/10/msg00023.html C'est du gaspillage, alors que si le système est géré par Debian, /boot/{config,vmlinuz,initrd}-$(uname -r) contient l'information nécessaire.
Mais cela ne garanti pas que le noyau n'a pas été altéré. L'économie de ~200 Ko de RAM me semble être une excuse fallacieuse et, si on va par là, le "gaspillage" est tout aussi avéré sur le disque. Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système. -- Chez les vieilles qui trafiquent le spleen, T'as bouffé tes nerfs et tes nuits Et maintenant tu cherches une combine Pour domestiquer nos envies. -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Doug713705
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c040e10$0$21606$) :
Doug713705 , dans le message <pu0sal$rk3$, a écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en permanence.
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 2018-12-02, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5c040e10$0$21606$426a74cc@news.free.fr>) :
Doug713705 , dans le message <pu0sal$rk3$1@golgoth99.hacktruck.net>, a
écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé
par Debian (et bien d'autres). Cela permet de vérifier la configuration
du noyau en cours d'utilisation quand un fichier dans /boot ne garanti
pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un
pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en
permanence.
Je comprends cet argument si on parle de système disposant de très peu
de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas
l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas
(iie. altération du noyau ou altération du fichier) où l'information fournie
par le noyau peut être différente de celle fourni par un fichier déposé
dans /boot.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c040e10$0$21606$) :
Doug713705 , dans le message <pu0sal$rk3$, a écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en permanence.
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Marc SCHAEFER
Doug713705 wrote:
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela ne sera pas altéré. Si tu modifies hors de tout contrôle ... alors tu ne mérites pas Debian :)
Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou 4GB de RAM, ça va bien.
Doug713705 <doug.letough@free.fr> wrote:
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela
ne sera pas altéré.
Si tu modifies hors de tout contrôle ... alors tu ne mérites
pas Debian :)
Desactiver cette option sur des systèmes embarqués disposant de peu de
RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur
ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur
mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou
4GB de RAM, ça va bien.
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela ne sera pas altéré. Si tu modifies hors de tout contrôle ... alors tu ne mérites pas Debian :)
Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou 4GB de RAM, ça va bien.
Doug713705
Le 2018-12-02, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pu158d$c9n$) :
Doug713705 wrote:
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela ne sera pas altéré. Si tu modifies hors de tout contrôle ... alors tu ne mérites pas Debian :)
C'eet vrai, je mérite une Slackware :) Mais je ne parlais pas de moi mais de quelqu'un de moins bien intentionné.
Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou 4GB de RAM, ça va bien.
Voilà, tu n'es plus à 200Ko de RAM près. -- Mais dans les souterrains, les rêveurs sont perdants. Serions-nous condamnés à nous sentir trop lourds ? H.F. Thiéfaine- 713705 Cherche Futur
Le 2018-12-02, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration
(<pu158d$c9n$1@shakotay.alphanet.ch>) :
Doug713705 <doug.letough@free.fr> wrote:
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela
ne sera pas altéré.
Si tu modifies hors de tout contrôle ... alors tu ne mérites
pas Debian :)
C'eet vrai, je mérite une Slackware :)
Mais je ne parlais pas de moi mais de quelqu'un de moins bien
intentionné.
Desactiver cette option sur des systèmes embarqués disposant de peu de
RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur
ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur
mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou
4GB de RAM, ça va bien.
Voilà, tu n'es plus à 200Ko de RAM près.
--
Mais dans les souterrains, les rêveurs sont perdants.
Serions-nous condamnés à nous sentir trop lourds ?
H.F. Thiéfaine- 713705 Cherche Futur
Le 2018-12-02, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pu158d$c9n$) :
Doug713705 wrote:
Mais cela ne garanti pas que le noyau n'a pas été altéré.
Si tu utilises les packages pour mettre à jour ton kernel, cela ne sera pas altéré. Si tu modifies hors de tout contrôle ... alors tu ne mérites pas Debian :)
C'eet vrai, je mérite une Slackware :) Mais je ne parlais pas de moi mais de quelqu'un de moins bien intentionné.
Desactiver cette option sur des systèmes embarqués disposant de peu de RAM se comprend tout à fait mais on n'utilise pas un noyau générique sur ce genre de système.
Cet argument est par contre recevable à mon avis. Encore que sur mes apu2, je mets le kernel de Debian maintenant, avec 2 GB ou 4GB de RAM, ça va bien.
Voilà, tu n'es plus à 200Ko de RAM près. -- Mais dans les souterrains, les rêveurs sont perdants. Serions-nous condamnés à nous sentir trop lourds ? H.F. Thiéfaine- 713705 Cherche Futur
Nicolas George
Doug713705 , dans le message <pu154m$fgf$, a écrit :
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Doug713705 , dans le message <pu154m$fgf$2@golgoth99.hacktruck.net>, a
écrit :
Je comprends cet argument si on parle de système disposant de très peu
de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas
l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas
(iie. altération du noyau ou altération du fichier) où l'information fournie
par le noyau peut être différente de celle fourni par un fichier déposé
dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information
donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Doug713705 , dans le message <pu154m$fgf$, a écrit :
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Doug713705
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c0421e3$0$5495$) :
Doug713705 , dans le message <pu154m$fgf$, a écrit :
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz. -- Diogène ! Je te salue, Glaireux blaireau. Diogène ! Je te salue, Héros de la classe moins zéro. -- H.F. Thiéfaine, Diogène série 87
Le 2018-12-02, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5c0421e3$0$5495$426a74cc@news.free.fr>) :
Doug713705 , dans le message <pu154m$fgf$2@golgoth99.hacktruck.net>, a
écrit :
Je comprends cet argument si on parle de système disposant de très peu
de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas
l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas
(iie. altération du noyau ou altération du fichier) où l'information fournie
par le noyau peut être différente de celle fourni par un fichier déposé
dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information
donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière
involontaire un fichier dans /boot que de patcher le noyau pour en modifier
le comportement de l'accès à /proc/config.gz.
--
Diogène ! Je te salue,
Glaireux blaireau.
Diogène ! Je te salue,
Héros de la classe moins zéro.
-- H.F. Thiéfaine, Diogène série 87
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c0421e3$0$5495$) :
Doug713705 , dans le message <pu154m$fgf$, a écrit :
Je comprends cet argument si on parle de système disposant de très peu de RAM (embarqué, etc) mais sur du noyau générique je ne vois pas l'intérêt d'économiser ~200Ko de RAM alors qu'il existe des cas (iie. altération du noyau ou altération du fichier) où l'information fournie par le noyau peut être différente de celle fourni par un fichier déposé dans /boot.
Si tu vas par là, il peut également y avoir des cas où l'information donnée par /proc ne correspond pas à ce que fait effectivement le noyau.
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz. -- Diogène ! Je te salue, Glaireux blaireau. Diogène ! Je te salue, Héros de la classe moins zéro. -- H.F. Thiéfaine, Diogène série 87
Nicolas George
Doug713705 , dans le message <pu1cqs$sev$, a écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver l'intégralité des fichiers tels que distribués. Autre argument : va consulter /proc/config.gz depuis un autre noyau que celui concerné...
Doug713705 , dans le message <pu1cqs$sev$1@golgoth99.hacktruck.net>, a
écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière
involontaire un fichier dans /boot que de patcher le noyau pour en modifier
le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver
l'intégralité des fichiers tels que distribués.
Autre argument : va consulter /proc/config.gz depuis un autre noyau que
celui concerné...
Doug713705 , dans le message <pu1cqs$sev$, a écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver l'intégralité des fichiers tels que distribués. Autre argument : va consulter /proc/config.gz depuis un autre noyau que celui concerné...
Pascal Hambourg
Le 02/12/2018 à 17:53, Nicolas George a écrit :
Doug713705 , dans le message <pu0sal$rk3$, a écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en permanence.
Et quand on est dans un conteneur sur un VPS, on fait comment ? Il y a aussi /boot ?
Le 02/12/2018 à 17:53, Nicolas George a écrit :
Doug713705 , dans le message <pu0sal$rk3$1@golgoth99.hacktruck.net>, a
écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé
par Debian (et bien d'autres). Cela permet de vérifier la configuration
du noyau en cours d'utilisation quand un fichier dans /boot ne garanti
pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un
pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en
permanence.
Et quand on est dans un conteneur sur un VPS, on fait comment ? Il y a
aussi /boot ?
Doug713705 , dans le message <pu0sal$rk3$, a écrit :
Ceci dit je ne comprends pas pourquoi CONFIG_IKCONFIG n'est pas activé par Debian (et bien d'autres). Cela permet de vérifier la configuration du noyau en cours d'utilisation quand un fichier dans /boot ne garanti pas qu'il correspond au noyau en cours.
Un fichier dans /boot, c'est juste un fichier dans /boot. Un pseudo-fichier dans /proc, c'est du code dans le noyau, en mémoire en permanence.
Et quand on est dans un conteneur sur un VPS, on fait comment ? Il y a aussi /boot ?
Nicolas George
Pascal Hambourg , dans le message <pu1f3h$1m3$, a écrit :
Et quand on est dans un conteneur sur un VPS, on fait comment ?
Pour faire quoi ?
Pascal Hambourg , dans le message <pu1f3h$1m3$1@saria.nerim.net>, a
écrit :
Et quand on est dans un conteneur sur un VPS, on fait comment ?
Pascal Hambourg , dans le message <pu1f3h$1m3$, a écrit :
Et quand on est dans un conteneur sur un VPS, on fait comment ?
Pour faire quoi ?
Doug713705
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c0439e2$0$11055$) :
Doug713705 , dans le message <pu1cqs$sev$, a écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver l'intégralité des fichiers tels que distribués. Autre argument : va consulter /proc/config.gz depuis un autre noyau que celui concerné...
Bon argument mais l'un n'empèche pas l'autre. -- Dans cet étrange carnaval On a vendu l'homo sapiens Pour racheter du Neandertal -- H.F. Thiéfaine, Aligator 427
Le 2018-12-02, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5c0439e2$0$11055$426a34cc@news.free.fr>) :
Doug713705 , dans le message <pu1cqs$sev$1@golgoth99.hacktruck.net>, a
écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière
involontaire un fichier dans /boot que de patcher le noyau pour en modifier
le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver
l'intégralité des fichiers tels que distribués.
Autre argument : va consulter /proc/config.gz depuis un autre noyau que
celui concerné...
Bon argument mais l'un n'empèche pas l'autre.
--
Dans cet étrange carnaval
On a vendu l'homo sapiens
Pour racheter du Neandertal
-- H.F. Thiéfaine, Aligator 427
Le 2018-12-02, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5c0439e2$0$11055$) :
Doug713705 , dans le message <pu1cqs$sev$, a écrit :
Il reste nénmoins beaucoup plus facile de perdre/corrompre de manière involontaire un fichier dans /boot que de patcher le noyau pour en modifier le comportement de l'accès à /proc/config.gz.
Mais si on utilise un noyau packagé, il est très facile de retrouver l'intégralité des fichiers tels que distribués. Autre argument : va consulter /proc/config.gz depuis un autre noyau que celui concerné...
Bon argument mais l'un n'empèche pas l'autre. -- Dans cet étrange carnaval On a vendu l'homo sapiens Pour racheter du Neandertal -- H.F. Thiéfaine, Aligator 427
