On Jun 16, 7:54pm, rhin...@epost.ch (rhin...@epost.ch) wrote: -- Subject: Re: Security and PAX
| On Mon, Jun 15, 2015 at 09:59:34AM -0400, Christos Zoulas wrote: | > On Jun 15, 9:15am, rhin...@epost.ch (rhin...@epost.ch) wrote: | > -- Subject: Re: Security and PAX | > | > | I will send you this info soon. Should I recompile Userland programs and libs | > | with the parameter "-fpic". If I remember well, it was the library | > | "libtermcap" (from userland) which cannot be linked and the error | > | message suggested to compile it with "-fpic". | > | > Ah, for this link all the archive libraries into the binary you need to create | > libfoo_pic.a for each one of them like you have for libc... It is not hard | > to do, but we don't do it by default because people don't need it and it | > takes more time and space. | > | The needed libraries are already in NetBSD and I could use them. | Hoewever, I get a new error message when I try to do manually | the link command: | ---------------------------------------------------------------------------------------------- | virtualisation# cc -static -Wl,-I/libexec/ld.elf_so -Wl,-pie -o zsh main.o `cat stamp-modobjs` -lc_pic -ltermcap_pic -lrt_pic -lm_pic | ld: /usr/lib/libc.a(errx.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC | /usr/lib/libc.a: could not read symbols: Bad value | ---------------------------------------------------------------------------------------------- | | I don't understand well the meaning of "R_X86_64_32" since I compile | in 64 bits (what mean "32"?) as you can see in the static version of the executable: This means that you are picking up some code that it is not PIC; the 32 here means 32 bit offsets. The order of the libraries is wrong, you need to put -lc_pic last because the others depend on symbols from it. There is a way to cheat by repeating all the libraries twice :-) christos
