* Andy Lutomirski: > I didn’t add a flag because the vsyscall page was thoroughly obsolete > when all this happened, and I wanted to encourage all new code to just > parse the vDSO instead of piling on the hacks. It turned out that the thorny cases just switched to system calls instead. I think we finally completed the transition in glibc upstream in 2018 (for x86). > Anyway, you may be the right person to ask: is there some credible way > that the kernel could detect new binaries that don’t need vsyscalls? > Maybe a new ELF note on a static binary or on the ELF interpreter? We > can dynamically switch it in principle. For this kind of change, markup similar to PT_GNU_STACK would have been appropriate, I think: Old kernels and loaders would have ignored the program header and loaded the program anyway, but the vsyscall page still existed, so that would have been fine. The kernel would have needed to check the program interpreter or the main executable (without a program interpreter, i.e., the statically linked case). Due the way the vsyscalls are concentrated in glibc, a dynamically linked executable would not have needed checking (or re-linking). I don't think we would have implemented the full late enablement after dlopen we did for executable stacks. In theory, any code could have jumped to the vsyscall area, but in practice, it's just dynamically linked glibc and static binaries. But nowadays, unmarked glibcs which do not depend on vsyscall vastly outnumber unmarked glibcs which requrie it. Therefore, markup of binaries does not seem to be reasonable to day. I could imagine a personality flag you can set (if yoy have CAP_SYS_ADMIN) that re-enables vsyscall support for new subprocesses. And a container runtime would do this based on metadata found in the image. This way, the container host itself could be protected, and you could still run legacy images which require vsyscall. For the non-container case, if you know that you'll run legacy workloads, you'd still have the boot parameter. But I think it could default to vsyscall=none in many more cases. Thanks, Florian
