* Andy Lutomirski: >> On Feb 11, 2021, at 2:05 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> In glibc, we have some code that copies the DT_SONAME string of the >> kernel vDSO into the heap, commented this way: >> >> /* Work around a kernel problem. The kernel cannot handle >> addresses in the vsyscall DSO pages in writev() calls. */ >> >> Is this really a problem anymore? vDSO addresses are ordinary userspace >> addresses, I think. (The vsyscall stuff is very different, of course, >> and maybe the vDSO started out the same way.) > > I don’t think it was ever a problem, and it certainly haven’t been a > problem for a long, long time. vDSO addresses are regular user > addresses. The *vsyscall* addresses are not, and most syscalls will > not accept them, but that shouldn’t matter especially since modern > kernels, by default, won’t let you read those addresses from user code > either. Thanks. Patch posted: <https://sourceware.org/pipermail/libc-alpha/2021-February/122603.html> > Saying “vsyscall DSO” is odd. There’s no such thing. In the glibc context, it sometimes means “system-call-like function implemented in the vDSO”. But that's not the case here. Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
