(RANDSTRUCT) nuit à la performance, parce que les structures du noyau sont soigneusement optimisées pour l'ordre optimal, prenant aussi en compte les effets de cache.

Ca tombe bien, il y a depuis longtemps (toujours ?) RANDSTRUCT_PERFORMANCE, qui tient compte des lignes de cache, au prix d'une randomisation moindre.

Ça rend les compilations non-reproduisibles. (En particulier, ça va directement à l'encontre de l'effort "reproducible builds" si cher à Debian qui t'est si chère.)

D'après ce que je vois dans la config du kernel grsec Debian, RANDSTRUCT + RANDSTRUCT_PERFORMANCE sont activés, donc le package kernel grsec Debian n'a pas l'air concerné.
Corsac, qui s'occupe de ces packages, est un chercheur en sécurité, et il a raison de mettre RANDSTRUCT.

Ça randomise en temps de compilation, donc ça ne sert pas à grand chose pour une grosse distribution comme Fedora ou Debian où des milliers d'utilisateurs utilisent le même binaire de noyau, publiquement téléchargeable. Il faut compiler son propre noyau pour que ça serve vraiment.

C'est exact, et c'est du reste ce que je fais sur celles des diverses machines que j'administre sur lesquelles j'ai installé des kernels grsec.
Cependant, comme RANDSTRUCT change à chaque build du kernel, et qu'il y en a tous les quelques jours... même avec des kernels distro, il est évident que c'est vite chiant pour les attaquants de faire des exploits binaires contre des kernels grsec (surtout qu'ils ont énormément moins d'infoleaks sur le kernel mainline, que l'ASLR est plus fort, etc.). Bref, le compromis n'est pas idiot, et c'est clairement mieux qu'un kernel mainline plus largement utilisé, faible en auto-protection, et qui ne randomise rien !

La bonne solution est d'explicitement marquer const les structures qui devraient l'être, pas d'essayer de le deviner magiquement et d'exiger __no_const partout où l'heuristique se trompe. Aussi parce que faire ça magiquement fait que les développeurs prennent la mauvaise habitude de s'attendre à ça, de ne plus rien marquer const, et du coup, s'il y a un faux négatif, la sécurité diminue au lieu d'augmenter.

Mais l'histoire a montré que 1) les devs kernel ne mettent pas const là où il faut, 2) même quand on leur mâche le boulot (soumission de patches individuels de constification - Emese Revfy l'a fait il y a des années), le taux d'acceptation de tels patches par les mainteneurs est dégueulasse, et 3) comme checkpatch.pl ne flagge pas la plupart des structures qui devraient être constifiées, de la merde continue à être injectée dans le tuyau à chaque release, sans que les contributeurs sachent qu'ils sont en train de mal faire...
CONSTIFY n'a pas toujours été écrit comme plugin GCC. En 2011, c'était encore une liste d'ajouts de "const", représentant environ le tiers de PaX, qui ne faisait qu'environ 2 MB à l'époque (il a triplé depuis, et grsec est encore plus long !). C'était chiant à maintenir. Non seulement le fait de passer à un plugin GCC a gagné du temps à Emese Revfy, lui permettant de se concentrer sur d'autres tâches utiles, mais si je me souviens bien, le plugin a constifié des structures qui ne l'étaient pas dans la version manuelle de la constification.
CONSTIFY n'est pas parfait, mais encore une fois, c'est une bien meilleure solution que le kernel mainline, parce que s'appliquant à beaucoup plus d'instances de structs ops... Sur un kernel mainline, la constification éparse est parfois la dernière ligne de défense, vu que le kernel mainline déférence sans problème une struct ops créée par l'attaquant en user-space (sauf processeurs rares, et encore faudrat-il que l'implémentation de mainline soit correcte, le contraire a été brillamment démontré ces jours-ci), et exécute sans broncher le payload user-space pointé par la struct ops du user-space (sauf processeurs un peu moins rares). Mais si la constification empêche l'attaquant d'écrire là où il voudrait, c'est déjà ça de gagné.