Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
On Mon, Jan 10, 2022 at 06:26:54PM +0100, Heiko Carstens wrote: > On Mon, Jan 10, 2022 at 04:23:05PM +0100, Alexander Egorenkov wrote: > > Heiko Carstens writes: > > > Given that Alexander is currently not available, I will resend his > > > patch with an updated commit message. > > > > Many thanks for the review and taking care of the review finding. > > But it looks like this still hasn't been applied to the kexec-tools > git tree, unless I'm mistaken(?) Sorry for the delay, I have now applied v2. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
On Mon, Jan 10, 2022 at 04:23:05PM +0100, Alexander Egorenkov wrote: > Heiko Carstens writes: > > Given that Alexander is currently not available, I will resend his > > patch with an updated commit message. > > Many thanks for the review and taking care of the review finding. But it looks like this still hasn't been applied to the kexec-tools git tree, unless I'm mistaken(?) ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Heiko Carstens writes: > > Given that Alexander is currently not available, I will resend his > patch with an updated commit message. Many thanks for the review and taking care of the review finding. Regards Alex ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
On Wed, Dec 15, 2021 at 01:43:00PM +0100, Simon Horman wrote: > On Mon, Dec 13, 2021 at 11:44:30AM +0100, Philipp Rudo wrote: > > Hi Alexander, > > > > @Alexander: Thanks for taking care of this. > > > > On Wed, 8 Dec 2021 13:53:55 +0100 > > Alexander Egorenkov wrote: > > > > > Starting with gcc 11.3, the C compiler will generate PLT-relative function > > > calls even if they are local and do not require it. Later on during > > > linking, > > > the linker will replace all PLT-relative calls to local functions with > > > PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is > > > not being linked as a regular executable or shared library would have > > > been, > > > and therefore, all PLT-relative addresses remain in the generated > > > purgatory > > > object code unresolved. This leads to the situation where the purgatory > > > code is being executed during kdump with all PLT-relative addresses > > > unresolved. And this results in endless loops within the purgatory code. > > > > Tiny nit. The last two sentences describe the situation in the kernel. > > Luckily the kexec-tools do proper error checking and die with > > > > "Unknown rela relocation: 0x14 0x73c0901c" > > > > when they encounter an unknown relocation type. > > > > Anyway, the code is correct > > > > Reviewed-by: Philipp Rudo > > Thanks. > > Alexander would you care to post a v2 with an updated patch description? Given that Alexander is currently not available, I will resend his patch with an updated commit message. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
On Mon, Dec 13, 2021 at 11:44:30AM +0100, Philipp Rudo wrote: > Hi Alexander, > > @Alexander: Thanks for taking care of this. > > On Wed, 8 Dec 2021 13:53:55 +0100 > Alexander Egorenkov wrote: > > > Starting with gcc 11.3, the C compiler will generate PLT-relative function > > calls even if they are local and do not require it. Later on during linking, > > the linker will replace all PLT-relative calls to local functions with > > PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is > > not being linked as a regular executable or shared library would have been, > > and therefore, all PLT-relative addresses remain in the generated purgatory > > object code unresolved. This leads to the situation where the purgatory > > code is being executed during kdump with all PLT-relative addresses > > unresolved. And this results in endless loops within the purgatory code. > > Tiny nit. The last two sentences describe the situation in the kernel. > Luckily the kexec-tools do proper error checking and die with > > "Unknown rela relocation: 0x14 0x73c0901c" > > when they encounter an unknown relocation type. > > Anyway, the code is correct > > Reviewed-by: Philipp Rudo Thanks. Alexander would you care to post a v2 with an updated patch description? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Hi Alexander, @Alexander: Thanks for taking care of this. On Wed, 8 Dec 2021 13:53:55 +0100 Alexander Egorenkov wrote: > Starting with gcc 11.3, the C compiler will generate PLT-relative function > calls even if they are local and do not require it. Later on during linking, > the linker will replace all PLT-relative calls to local functions with > PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is > not being linked as a regular executable or shared library would have been, > and therefore, all PLT-relative addresses remain in the generated purgatory > object code unresolved. This leads to the situation where the purgatory > code is being executed during kdump with all PLT-relative addresses > unresolved. And this results in endless loops within the purgatory code. Tiny nit. The last two sentences describe the situation in the kernel. Luckily the kexec-tools do proper error checking and die with "Unknown rela relocation: 0x14 0x73c0901c" when they encounter an unknown relocation type. Anyway, the code is correct Reviewed-by: Philipp Rudo > Furthermore, the clang C compiler has always behaved like described above > and this commit should fix the purgatory code built with the latter. > > Because the purgatory code is no regular executable or shared library, > contains only calls to local functions and has no PLT, all R_390_PLT32DBL > relocation entries can be resolved just like a R_390_PC32DBL one. > > * > https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x1633.html#AEN1699 > > Relocation entries of purgatory code generated with gcc 11.3 > > > $ readelf -r purgatory/purgatory.o > > Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: > Offset Info Type Sym. ValueSym. Name + > Addend > 000c 00030013 R_390_PC32DBL .data + 2 > 001a 00100014 R_390_PLT32DBL sha256_starts + > 2 > 0030 00110014 R_390_PLT32DBL sha256_update + > 2 > 0046 00120014 R_390_PLT32DBL sha256_finish + > 2 > 0050 00030013 R_390_PC32DBL .data + 102 > 005a 00130014 R_390_PLT32DBL memcmp + 2 > ... > 0118 00160014 R_390_PLT32DBL setup_arch + 2 > 011e 00030013 R_390_PC32DBL .data + 2 > 012c 000f0014 R_390_PLT32DBL > verify_sha256_digest + 2 > 0142 00170014 R_390_PLT32DBL > post_verification[...] + 2 > > Relocation entries of purgatory code generated with gcc 11.2 > > > $ readelf -r purgatory/purgatory.o > > Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: > Offset Info Type Sym. ValueSym. Name + > Addend > 000e 00030013 R_390_PC32DBL .data + 2 > 001c 00100013 R_390_PC32DBL sha256_starts + > 2 > 0036 00110013 R_390_PC32DBL sha256_update + > 2 > 0048 00120013 R_390_PC32DBL sha256_finish + > 2 > 0052 00030013 R_390_PC32DBL .data + 102 > 005c 00130013 R_390_PC32DBL memcmp + 2 > ... > 011a 00160013 R_390_PC32DBL setup_arch + 2 > 0120 00030013 R_390_PC32DBL .data + 122 > 0130 000f0013 R_390_PC32DBL > verify_sha256_digest + 2 > 0146 00170013 R_390_PC32DBL > post_verification[...] + 2 > > Corresponding s390 kernel discussion: > * > https://lore.kernel.org/linux-s390/20211208105801.188140-1-egore...@linux.ibm.com/T/#u > > Signed-off-by: Alexander Egorenkov > Reported-by: Tao Liu > Suggested-by: Philipp Rudo > --- > kexec/arch/s390/kexec-elf-rel-s390.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kexec/arch/s390/kexec-elf-rel-s390.c > b/kexec/arch/s390/kexec-elf-rel-s390.c > index a5e1b7345578..91ba86a9991d 100644 > --- a/kexec/arch/s390/kexec-elf-rel-s390.c > +++ b/kexec/arch/s390/kexec-elf-rel-s390.c > @@ -56,6 +56,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), > case R_390_PC16:/* PC relative 16 bit. */ > case R_390_PC16DBL: /* PC relative 16 bit shifted by 1. */ > case R_390_PC32DBL: /* PC relative 32 bit shifted by 1. */ > + case R_390_PLT32DBL:/* 32 bit PC rel. PLT shifted by 1. */ > case R_390_PC32:/* PC relative 32 bit. */ > case R_390_PC64:/* PC relative 64 bit. */ > val -= address; > @@ -63,7 +64,7 @@ void machine_apply_elf_rel(struct mem_ehdr
[PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Starting with gcc 11.3, the C compiler will generate PLT-relative function calls even if they are local and do not require it. Later on during linking, the linker will replace all PLT-relative calls to local functions with PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is not being linked as a regular executable or shared library would have been, and therefore, all PLT-relative addresses remain in the generated purgatory object code unresolved. This leads to the situation where the purgatory code is being executed during kdump with all PLT-relative addresses unresolved. And this results in endless loops within the purgatory code. Furthermore, the clang C compiler has always behaved like described above and this commit should fix the purgatory code built with the latter. Because the purgatory code is no regular executable or shared library, contains only calls to local functions and has no PLT, all R_390_PLT32DBL relocation entries can be resolved just like a R_390_PC32DBL one. * https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x1633.html#AEN1699 Relocation entries of purgatory code generated with gcc 11.3 $ readelf -r purgatory/purgatory.o Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: Offset Info Type Sym. ValueSym. Name + Addend 000c 00030013 R_390_PC32DBL .data + 2 001a 00100014 R_390_PLT32DBL sha256_starts + 2 0030 00110014 R_390_PLT32DBL sha256_update + 2 0046 00120014 R_390_PLT32DBL sha256_finish + 2 0050 00030013 R_390_PC32DBL .data + 102 005a 00130014 R_390_PLT32DBL memcmp + 2 ... 0118 00160014 R_390_PLT32DBL setup_arch + 2 011e 00030013 R_390_PC32DBL .data + 2 012c 000f0014 R_390_PLT32DBL verify_sha256_digest + 2 0142 00170014 R_390_PLT32DBL post_verification[...] + 2 Relocation entries of purgatory code generated with gcc 11.2 $ readelf -r purgatory/purgatory.o Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: Offset Info Type Sym. ValueSym. Name + Addend 000e 00030013 R_390_PC32DBL .data + 2 001c 00100013 R_390_PC32DBL sha256_starts + 2 0036 00110013 R_390_PC32DBL sha256_update + 2 0048 00120013 R_390_PC32DBL sha256_finish + 2 0052 00030013 R_390_PC32DBL .data + 102 005c 00130013 R_390_PC32DBL memcmp + 2 ... 011a 00160013 R_390_PC32DBL setup_arch + 2 0120 00030013 R_390_PC32DBL .data + 122 0130 000f0013 R_390_PC32DBL verify_sha256_digest + 2 0146 00170013 R_390_PC32DBL post_verification[...] + 2 Corresponding s390 kernel discussion: * https://lore.kernel.org/linux-s390/20211208105801.188140-1-egore...@linux.ibm.com/T/#u Signed-off-by: Alexander Egorenkov Reported-by: Tao Liu Suggested-by: Philipp Rudo --- kexec/arch/s390/kexec-elf-rel-s390.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kexec/arch/s390/kexec-elf-rel-s390.c b/kexec/arch/s390/kexec-elf-rel-s390.c index a5e1b7345578..91ba86a9991d 100644 --- a/kexec/arch/s390/kexec-elf-rel-s390.c +++ b/kexec/arch/s390/kexec-elf-rel-s390.c @@ -56,6 +56,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), case R_390_PC16:/* PC relative 16 bit. */ case R_390_PC16DBL: /* PC relative 16 bit shifted by 1. */ case R_390_PC32DBL: /* PC relative 32 bit shifted by 1. */ + case R_390_PLT32DBL:/* 32 bit PC rel. PLT shifted by 1. */ case R_390_PC32:/* PC relative 32 bit. */ case R_390_PC64:/* PC relative 64 bit. */ val -= address; @@ -63,7 +64,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), *(unsigned short *) loc = val; else if (r_type == R_390_PC16DBL) *(unsigned short *) loc = val >> 1; - else if (r_type == R_390_PC32DBL) + else if (r_type == R_390_PC32DBL || r_type == R_390_PLT32DBL) *(unsigned int *) loc = val >> 1; else if (r_type == R_390_PC32) *(unsigned int *) loc = val; -- 2.31.1 ___ kexec mailing list kexec@lists.infradead.org
