J'espère que ces explications éclaireront mon propos, et surtout permettront aux gens de comprendre qu'il n'y a aucun jugement ici
T'inquiètes, mon propos n'étais absolument pas de ce type.
Je me posais vraiment la question sur ce point précis, puisque je l'ai vu passer dans un bugtracker: un bug spécifique à Slackware, de mémoire non rencontré sur gentoo, et je ne sais pas pour LFS mais de toute façons, LFS c'est pas une distro.
Pour le reste, je rejoins en partie ton avis, mais je considère personnellement que les réglages du noyau spécifiques à une distro sont... spécifiques à la distro, justement, d'autant plus s'ils ont un impact sur le userland.
Dans ce cas précis, non, ça ne sera pas la seule application, j'en ai vu d'autres listées sur le wiki de debian (pas beaucoup, certes, moins d'une dizaine) et on parle au final d'un truc assez spécifique.
La ou ça serait une faille de sécurité, mais pas un "trou béant" au final, c'est si l'application fait des accès mémoire foireux (pas improbable, je sais), alors que typiquement, un émulateur de système (DOS, par example) utiliseras les pages basses de la mémoire par simplicité/réalisme.
Ici, unvanquished utilise NaCL pour exécuter le code des mods. Je ne connais pas assez les détails, mais je ne serais pas surpris que ça soit la cause racine, et je serais surpris que seul unvanquished ait utilisé NaCl.
J'aurai bien aimé voir la valeur par défaut de slackware, ça m'aurait permis d'essayer de raisonner un peu sur le "ils savent configurer un noyau mais on le savait déjà". Les mesures de mitigations, pour moi, peuvent vite devenir cause de code legacy oublié de tous quand les raisons n'en sont pas connue (bus factor).
[^] # Re: Une grande inconnue
Posté par freem . En réponse au journal Slackware 15 en approche ?. Évalué à 2.
T'inquiètes, mon propos n'étais absolument pas de ce type.
Je me posais vraiment la question sur ce point précis, puisque je l'ai vu passer dans un bugtracker: un bug spécifique à Slackware, de mémoire non rencontré sur gentoo, et je ne sais pas pour LFS mais de toute façons, LFS c'est pas une distro.
Pour le reste, je rejoins en partie ton avis, mais je considère personnellement que les réglages du noyau spécifiques à une distro sont... spécifiques à la distro, justement, d'autant plus s'ils ont un impact sur le userland.
Dans ce cas précis, non, ça ne sera pas la seule application, j'en ai vu d'autres listées sur le wiki de debian (pas beaucoup, certes, moins d'une dizaine) et on parle au final d'un truc assez spécifique.
La ou ça serait une faille de sécurité, mais pas un "trou béant" au final, c'est si l'application fait des accès mémoire foireux (pas improbable, je sais), alors que typiquement, un émulateur de système (DOS, par example) utiliseras les pages basses de la mémoire par simplicité/réalisme.
Ici, unvanquished utilise NaCL pour exécuter le code des mods. Je ne connais pas assez les détails, mais je ne serais pas surpris que ça soit la cause racine, et je serais surpris que seul unvanquished ait utilisé NaCl.
J'aurai bien aimé voir la valeur par défaut de slackware, ça m'aurait permis d'essayer de raisonner un peu sur le "ils savent configurer un noyau mais on le savait déjà". Les mesures de mitigations, pour moi, peuvent vite devenir cause de code legacy oublié de tous quand les raisons n'en sont pas connue (bus factor).