On 28/11/2019 13:48, H. Nikolaus Schaller wrote: > >> Am 28.11.2019 um 14:29 schrieb Maarten ter Huurne : >> >> On Thursday, 28 November 2019 13:33:17 CET H. Nikolaus Schaller wrote: >>> Hi Vincenzo, >>> >>>> Am 28.11.2019 um 13:21 schrieb Vincenzo Frascino >>>> :> >>>> [...] >>>> The the lib that provides the gettimeofday() changes accordingly >>>> with vdso_data. 5.4 and 4.19 have 2 different vdso libraries as >>>> well. >>> >>> Yes, that is what I have assumed what happens. How do these libs go >>> into an existing and working root-file-system with Debian Stretch? >> >> I'm a novice when it comes to vDSO, so someone please correct me if I'm >> wrong. >> >> From what I read vDSO is a library in the sense that it exports ELF >> symbols that applications and other libraries (libc in particular) can >> use, but it is not a file on disk. > > Ah, ok. This would mean that the libc providing the gettimeofday() > should be able to find out a modified changed vdso_data format by > inspecting these ELF symbols. > I agree with Maarten here. There is a discovery mechanism in the libc based on AT_SYSINFO_EHDR. This contains the address at which the vdso library is mapped by the kernel to the userspace process. >> >> As such, which rootfs you use shouldn't matter, since the vDSO is not in >> the rootfs. Instead, it is contained in the kernel image. Searching for >> "linux-vdso.so.1" on packages.debian.org indeed returns no hits. >> >> There is a check in arch/mips/vdso/Makefile that disables vDSO on MIPS >> when building the kernel with binutils < 2.25. I don't know if that is >> in any way related to this issue. > > What still does not fit into the picture is the errno = 1 i.e. EPERM. > Maybe I have to study the libc code that tries to read the ELF symbols > you have mentioned. It may fail for unknown reasons. > This is what I was going to suggest next. It might be that something is not working there. Let us know your findings. > BR and thanks, > Nikolaus > -- Regards, Vincenzo