* Linus Torvalds <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
