> On Jun 26, 2019, at 8:00 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * 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. > 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? Would enterprise distros consider backporting such a thing? I
