* Linus Torvalds <torvalds@xxxxxxxx> wrote: > Backwards compatibility is absolutely paramount. Much more important > than just about anything else. ok, and i agree that in this particular case we should not break older glibc. And that's the primary direction i'm going into: i've been trying to create CONFIG_COMPAT_VDSO [which defaults to =y] variants that both keep old glibc working and still have the randomization code active. Having the code active by default is very important because breakages get noticed early on, etc. But wrt. binary compatibility, the vdso (ignoring for a moment that it's tied to other parts of glibc) is kind of border line. Nothing but glibc knows about its internal structure. So i dont think "binary compatibility" per se is violated: no app breaks. This is more analogous to the situation where say old modutils cannot read new modules and the kernel wont boot at all. The _real_ argument i think, and the biggest practical difference is that glibc is _much harder to upgrade_ than other system utilities. So by _that_ argument i'd say we should avoid forcing a glibc dependency whenever possible - and that might as well be the right thing to do in this particular case. Also, what makes this a bit different for me is that this is a security feature which always has a "should the fire-door be default-open or default-closed" type of question, and that's why i'm reluctant to give up - and at least have compat-vdso code working that triggers most of the randomization codepaths too. Ingo
