Le 25/03/2021 à 17:46, Christophe Leroy a écrit :
Hi Laurent
Le 25/03/2021 à 17:11, Laurent Dufour a écrit :
Hi Christophe,
Since v5.11 and the changes you made to the VDSO code, it no more exposing the
ELF header at the beginning of the VDSO mapping in user space.
This is confusing CRIU which is checking for this ELF header cookie
(https://github.com/checkpoint-restore/criu/issues/1417).
How does it do on other architectures ?
Good question, I'll double check the CRIU code.
I'm not an expert in loading and ELF part and reading the change you made, I
can't identify how this could work now as I'm expecting the loader to need
that ELF header to do the relocation.
I think the loader is able to find it at the expected place.
Actually, it seems the loader relies on the AUX vector AT_SYSINFO_EHDR. I guess
CRIU should do the same.
From my investigation it seems that the first bytes of the VDSO area are now
the vdso_arch_data.
Is the ELF header put somewhere else?
How could the loader process the VDSO without that ELF header?
Like most other architectures, we now have the data section as first page and
the text section follows. So you will likely find the elf header on the second
page.
Done in this commit:
https://github.com/linuxppc/linux/commit/511157ab641eb6bedd00d62673388e78a4f871cf
I'll double check on x86, but anyway, I think CRIU should rely on
AT_SYSINFO_EHDR and not assume that the ELF header is at the beginning of VDSO
mapping.
Thanks for your help.
Laurent.
