| Age | Commit message (Collapse) | Author |
|---|
|
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 in turn lets kexec-tools fail with
"Unknown rela relocation: 0x14 0x73c0901c" for such relocation types.
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. Value Sym. Name + Addend
00000000000c 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000001a 001000000014 R_390_PLT32DBL 0000000000000000 sha256_starts + 2
000000000030 001100000014 R_390_PLT32DBL 0000000000000000 sha256_update + 2
000000000046 001200000014 R_390_PLT32DBL 0000000000000000 sha256_finish + 2
000000000050 000300000013 R_390_PC32DBL 0000000000000000 .data + 102
00000000005a 001300000014 R_390_PLT32DBL 0000000000000000 memcmp + 2
...
000000000118 001600000014 R_390_PLT32DBL 0000000000000000 setup_arch + 2
00000000011e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000012c 000f00000014 R_390_PLT32DBL 0000000000000000 verify_sha256_digest + 2
000000000142 001700000014 R_390_PLT32DBL 0000000000000000
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. Value Sym. Name + Addend
00000000000e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000001c 001000000013 R_390_PC32DBL 0000000000000000 sha256_starts + 2
000000000036 001100000013 R_390_PC32DBL 0000000000000000 sha256_update + 2
000000000048 001200000013 R_390_PC32DBL 0000000000000000 sha256_finish + 2
000000000052 000300000013 R_390_PC32DBL 0000000000000000 .data + 102
00000000005c 001300000013 R_390_PC32DBL 0000000000000000 memcmp + 2
...
00000000011a 001600000013 R_390_PC32DBL 0000000000000000 setup_arch + 2
000000000120 000300000013 R_390_PC32DBL 0000000000000000 .data + 122
000000000130 000f00000013 R_390_PC32DBL 0000000000000000 verify_sha256_digest + 2
000000000146 001700000013 R_390_PC32DBL 0000000000000000 post_verification[...] + 2
Corresponding s390 kernel discussion:
* https://lore.kernel.org/linux-s390/20211208105801.188140-1-egorenar@linux.ibm.com/T/#u
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reported-by: Tao Liu <ltao@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
[hca@linux.ibm.com: changed commit message as requested by Philipp Rudo]
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On PowerPC64 ABIv2 we need to look at the symbol to determine
if it has a local entry point. Pass struct mem_sym into
machine_apply_elf_rel() so we can.
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds kdump support for s390 to the kexec tool and enables the
"--load-panic" option. When loading the kdump kernel and ramdisk we add the
address of the crashkernel memory to the normal load address.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
--===============39718348520004598==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Milton,
first of all thanks for looking at the patches.
> 1) When patching the command line, you read the string from the
> optarg. While you clear the area in the kernel looking at
> COMMAND_LINE_SIZE, you do not limit the length that you copy into
> the kernel by this amount. This would seem like a buffer-overflow
> situation that could easily be trapped.
Yes, you're right. The kernel image could be damaged. Fixed.
> 2) I noticed your ramdisk code is quite similar in function to
> slurp_file in kexec/kexec.c. I realize this is probably a new
> function.
Fixed as well :)
> 3) Your elf-rel loading seem to not be implemented, but your probe
> returns 0 just like the image loader.
I think you're talking about the function machine_verify_elf_rel().
Unlike the probe functions this one should return 0 on error,
shouldn't it?
> 4) You seem to have several addresses hard-coded into the kexec-s390.h
> file. This would seem to limit the image you are loading, including
> any panic crash kernel options using the current scheme. I don't
> know your abi to know what other issues you might have with a more
> generic kexec to image interface. (It appears you setup your image
> to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes.
The hard coded addresses are part of the kernel abi. Nothing needs to
be changed here. Skipping the first 64k of the kernel image is ok too,
since you usually would only find a loader routine there which would
load the rest of the kernel image into ram and then start it.
If you are really interested you might have a look at
arch/s390/kernel/head.S in the kernel sources :)
Also we do not plan to use the kdump feature. It doesn't make too
much sense for the s390 architecture since we have already other
mechanisms which allow to reliably dump complete memory and register
contents at any given state of the system.
The patch below should be better (still against 1.101). Guess I will
come up with an improved kernel patch too.
Thanks,
Heiko
diffstat:
configure | 5 -
kexec/arch/s390/Makefile | 6 +
kexec/arch/s390/include/arch/options.h | 11 ++
kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++
kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.h | 25 ++++++
kexec/kexec-syscall.h | 7 +
purgatory/arch/s390/Makefile | 7 +
purgatory/arch/s390/include/limits.h | 54 +++++++++++++
purgatory/arch/s390/include/stdint.h | 24 +++++
11 files changed, 402 insertions(+), 1 deletion(-)
|
