Mathias Krause (minipli) rentre aussi quelques patches de temps en temps.
Des centaines de hunks de PaX/grsecurity sont de purs cleanups, certains n'améliorant même pas explicitement la sécurité, et ne font l'objet d'aucune controverse pour les pousser vers mainline. Un des exemples qui revient le plus souvent est la constification des structures ops. Une très grosse série de patches de constification avait été poussée vers mainline par Emese Revfy (ephox), et peu de développeurs avaient intégré les modifs de constification...
On peut également citer quelques dizaines de structures locales qui prennent de la place sur la pile et du temps d'exécution alors qu'elles pourraient être static (et souvent const), ou a contrario, quelques variables static pour lesquelles ce static n'a aucun intérêt puisque la première chose que fait la fonction qui les déclare est d'écraser leur valeur.
Nombre de ces hunks sont présents depuis des années, inchangés. L'incitation à les pousser vers upstream est faible, puisque le fait de faire une soumission prend du temps, et comme je l'ai mentionné plus haut, le taux d'intégration de ces patches a déjà été montré comme bas.
Un point de ton post ne me paraît pas techniquement correct: on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity: https://grsecurity.net/compare.php
A moins que tu veuilles dire par "incompatible avec LSM" que mainline insiste absolument pour que grsecurity passe par les fourches caudines de LSM, alors que spender explique depuis des années ( https://grsecurity.net/lsm.php ) que c'est parfaitement inadapté parce que LSM est très loin d'être assez puissant ? C'est hélas un fait que "c'est pas un LSM" est une des objections qui ont été formulées contre l'inclusion de grsec dans mainline - peu importe le fait que ça réduise énormément la puissance de la solution.
[^] # Re: Inclusion
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 5.
Mathias Krause (minipli) rentre aussi quelques patches de temps en temps.
Des centaines de hunks de PaX/grsecurity sont de purs cleanups, certains n'améliorant même pas explicitement la sécurité, et ne font l'objet d'aucune controverse pour les pousser vers mainline. Un des exemples qui revient le plus souvent est la constification des structures ops. Une très grosse série de patches de constification avait été poussée vers mainline par Emese Revfy (ephox), et peu de développeurs avaient intégré les modifs de constification...
On peut également citer quelques dizaines de structures locales qui prennent de la place sur la pile et du temps d'exécution alors qu'elles pourraient être static (et souvent const), ou a contrario, quelques variables static pour lesquelles ce static n'a aucun intérêt puisque la première chose que fait la fonction qui les déclare est d'écraser leur valeur.
Nombre de ces hunks sont présents depuis des années, inchangés. L'incitation à les pousser vers upstream est faible, puisque le fait de faire une soumission prend du temps, et comme je l'ai mentionné plus haut, le taux d'intégration de ces patches a déjà été montré comme bas.
Un point de ton post ne me paraît pas techniquement correct: on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity: https://grsecurity.net/compare.php
A moins que tu veuilles dire par "incompatible avec LSM" que mainline insiste absolument pour que grsecurity passe par les fourches caudines de LSM, alors que spender explique depuis des années ( https://grsecurity.net/lsm.php ) que c'est parfaitement inadapté parce que LSM est très loin d'être assez puissant ? C'est hélas un fait que "c'est pas un LSM" est une des objections qui ont été formulées contre l'inclusion de grsec dans mainline - peu importe le fait que ça réduise énormément la puissance de la solution.