* Andy Lutomirski: > I’m wondering if we can still do it: add a note or other ELF indicator > that says “I don’t need vsyscalls.” Then we can change the default > mode to “no vsyscalls if the flag is there, else execute-only > vsyscalls”. > > Would glibc go along with this? I think we can make it happen, at least for relatively recent glibc linked with current binutils. It's not trivial because it requires coordination among multiple projects. We have three or four widely used link editors now, but we could make it happen. (Although getting to PT_GNU_PROPERTY wasn't exactly easy.) > Would enterprise distros consider backporting such a thing? Enterprise distros aren't the problem here because they can't remove vsyscall support for quite a while due to existing customer binaries. For them, it would just be an additional (and welcome) hardening opportunity. The challenge here are container hosting platforms which have already disabled vsyscall, presumably to protect the container host itself. They would need to rebuild the container host userspace with the markup to keep it protected, and then they could switch to a kernel which has vsyscall-unless-opt-out logic. That seems to be a bit of a stretch because from their perspective, there's no problem today. My guess is that it would be easier to have a personality flag. Then they could keep the host largely as-is, and would “only” need a mechanism to pass through the flag from the image metadata to the actual container creation. It's still a change to the container host (and the kernel change is required as well), but it would not require relinking every statically linked binary. Thanks, Florian
