Re: [RFC PATCH 2/2] objtool/powerpc: Enhance objtool to fixup alternate feature relative addresses
Hi Nathan, On 4/23/24 5:58 AM, Nathan Chancellor wrote: Hi Sathvika, On Mon, Apr 22, 2024 at 02:52:06PM +0530, Sathvika Vasireddy wrote: Implement build-time fixup of alternate feature relative addresses for the out-of-line (else) patch code. Initial posting to achieve the same using another tool can be found at [1]. Idea is to implement this using objtool instead of introducing another tool since it already has elf parsing and processing covered. Introduce --ftr-fixup as an option to objtool to do feature fixup at build-time. Couple of issues and warnings encountered while implementing feature fixup using objtool are as follows: 1. libelf is creating corrupted vmlinux file after writing necessary changes to the file. Due to this, kexec is not able to load new kernel. It gives the following error: ELF Note corrupted ! Cannot determine the file type of vmlinux To fix this issue, after opening vmlinux file, make a call to elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not to touch the segment and section layout. It informs the library that the application will take responsibility for the layout of the file and that the library should not insert any padding between sections. 2. Fix can't find starting instruction warnings when run on vmlinux Objtool throws a lot of can't find starting instruction warnings when run on vmlinux with --ftr-fixup option. These warnings are seen because find_insn() function looks for instructions at offsets that are relative to the start of the section. In case of individual object files (.o), there are no can't find starting instruction warnings seen because the actual offset associated with an instruction is itself a relative offset since the sections start at offset 0x0. However, in case of vmlinux, find_insn() function fails to find instructions at the actual offset associated with an instruction since the sections in vmlinux do not start at offset 0x0. Due to this, find_insn() will look for absolute offset and not the relative offset. This is resulting in a lot of can't find starting instruction warnings when objtool is run on vmlinux. To fix this, pass offset that is relative to the start of the section to find_insn(). find_insn() is also looking for symbols of size 0. But, objtool does not store empty STT_NOTYPE symbols in the rbtree. Due to this, for empty symbols, objtool is throwing can't find starting instruction warnings. Fix this by ignoring symbols that are of size 0 since objtool does not add them to the rbtree. 3. Objtool is throwing unannotated intra-function call warnings when run on vmlinux with --ftr-fixup option. One such example: vmlinux: warning: objtool: .text+0x3d94: unannotated intra-function call .text + 0x3d94 = c0008000 + 3d94 = c00081d4 c00081d4: 45 24 02 48 bl c002a618 c002a610 : c002a610: 0e 01 4c 3c addis r2,r12,270 c002a610: R_PPC64_REL16_HA.TOC. c002a614: f0 6c 42 38 addir2,r2,27888 c002a614: R_PPC64_REL16_LO.TOC.+0x4 c002a618: a6 02 08 7c mflrr0 This is happening because we should be looking for destination symbols that are at absolute offsets instead of relative offsets. After fixing dest_off to point to absolute offset, there are still a lot of these warnings shown. In the above example, objtool is computing the destination offset to be c002a618, which points to a completely different instruction. find_call_destination() is looking for this offset and failing. Instead, we should be looking for destination offset c002a610 which points to system_reset_exception function. Even after fixing the way destination offset is computed, and after looking for dest_off - 0x8 in cases where the original offset is not found, there are still a lot of unannotated intra-function call warnings generated. This is due to symbols that are not properly annotated. So, for now, as a hack to curb these warnings, do not emit unannotated intra-function call warnings when objtool is run with --ftr-fixup option. TODO: This patch enables build time feature fixup only for powerpc little endian configs. There are boot failures with big endian configs. Posting this as an initial RFC to get some review comments while I work on big endian issues. [1] https://lore.kernel.org/linuxppc-dev/20170521010130.13552-1-npig...@gmail.com/ Co-developed-by: Nicholas Piggin Signed-off-by: Nicholas Piggin Signed-off-by: Sathvika Vasireddy When I build this series with LLVM 14 [1] (due to an issue I report below), I am getting a crash when CONFIG_FTR_FIXUP_SELFTEST is disabled. diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 544a65fda77b..95d2906ec814 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -427,7 +427,6 @@
Re: [RFC PATCH 2/2] objtool/powerpc: Enhance objtool to fixup alternate feature relative addresses
On Mon, Apr 22, 2024 at 6:25 PM Sathvika Vasireddy wrote: > > Implement build-time fixup of alternate feature relative addresses for > the out-of-line (else) patch code. Initial posting to achieve the same > using another tool can be found at [1]. Idea is to implement this using > objtool instead of introducing another tool since it already has elf > parsing and processing covered. > > Introduce --ftr-fixup as an option to objtool to do feature fixup at > build-time. > > Couple of issues and warnings encountered while implementing feature > fixup using objtool are as follows: > > 1. libelf is creating corrupted vmlinux file after writing necessary > changes to the file. Due to this, kexec is not able to load new > kernel. > > It gives the following error: > ELF Note corrupted ! > Cannot determine the file type of vmlinux > > To fix this issue, after opening vmlinux file, make a call to > elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not > to touch the segment and section layout. It informs the library > that the application will take responsibility for the layout of the > file and that the library should not insert any padding between > sections. > > 2. Fix can't find starting instruction warnings when run on vmlinux > > Objtool throws a lot of can't find starting instruction warnings > when run on vmlinux with --ftr-fixup option. > > These warnings are seen because find_insn() function looks for > instructions at offsets that are relative to the start of the section. > In case of individual object files (.o), there are no can't find > starting instruction warnings seen because the actual offset > associated with an instruction is itself a relative offset since the > sections start at offset 0x0. > > However, in case of vmlinux, find_insn() function fails to find > instructions at the actual offset associated with an instruction > since the sections in vmlinux do not start at offset 0x0. Due to > this, find_insn() will look for absolute offset and not the relative > offset. This is resulting in a lot of can't find starting instruction > warnings when objtool is run on vmlinux. > > To fix this, pass offset that is relative to the start of the section > to find_insn(). > > find_insn() is also looking for symbols of size 0. But, objtool does > not store empty STT_NOTYPE symbols in the rbtree. Due to this, > for empty symbols, objtool is throwing can't find starting > instruction warnings. Fix this by ignoring symbols that are of > size 0 since objtool does not add them to the rbtree. > > 3. Objtool is throwing unannotated intra-function call warnings > when run on vmlinux with --ftr-fixup option. > > One such example: > > vmlinux: warning: objtool: .text+0x3d94: > unannotated intra-function call > > .text + 0x3d94 = c0008000 + 3d94 = c00081d4 > > c00081d4: 45 24 02 48 bl c002a618 > > > c002a610 : > c002a610: 0e 01 4c 3c addis r2,r12,270 > c002a610: R_PPC64_REL16_HA.TOC. > c002a614: f0 6c 42 38 addir2,r2,27888 > c002a614: R_PPC64_REL16_LO.TOC.+0x4 > c002a618: a6 02 08 7c mflrr0 > > This is happening because we should be looking for destination > symbols that are at absolute offsets instead of relative offsets. > After fixing dest_off to point to absolute offset, there are still > a lot of these warnings shown. > > In the above example, objtool is computing the destination > offset to be c002a618, which points to a completely > different instruction. find_call_destination() is looking for this > offset and failing. Instead, we should be looking for destination > offset c002a610 which points to system_reset_exception > function. > > Even after fixing the way destination offset is computed, and > after looking for dest_off - 0x8 in cases where the original offset > is not found, there are still a lot of unannotated intra-function > call warnings generated. This is due to symbols that are not > properly annotated. > > So, for now, as a hack to curb these warnings, do not emit > unannotated intra-function call warnings when objtool is run > with --ftr-fixup option. > > TODO: > This patch enables build time feature fixup only for powerpc little > endian configs. There are boot failures with big endian configs. > Posting this as an initial RFC to get some review comments while I work > on big endian issues. > > [1] > https://lore.kernel.org/linuxppc-dev/20170521010130.13552-1-npig...@gmail.com/ > > Co-developed-by: Nicholas Piggin > Signed-off-by: Nicholas Piggin > Signed-off-by: Sathvika Vasireddy > --- > arch/Kconfig | 3 + > arch/powerpc/Kconfig | 5 + > arch/powerpc/Makefile | 5 + > arch/powerpc/include/asm/feature-fixups.h | 11 +- > arch/powerpc/kernel/vmlinux.lds.S | 14
Re: [RFC PATCH 2/2] objtool/powerpc: Enhance objtool to fixup alternate feature relative addresses
Hi Sathvika, On Mon, Apr 22, 2024 at 02:52:06PM +0530, Sathvika Vasireddy wrote: > Implement build-time fixup of alternate feature relative addresses for > the out-of-line (else) patch code. Initial posting to achieve the same > using another tool can be found at [1]. Idea is to implement this using > objtool instead of introducing another tool since it already has elf > parsing and processing covered. > > Introduce --ftr-fixup as an option to objtool to do feature fixup at > build-time. > > Couple of issues and warnings encountered while implementing feature > fixup using objtool are as follows: > > 1. libelf is creating corrupted vmlinux file after writing necessary > changes to the file. Due to this, kexec is not able to load new > kernel. > > It gives the following error: > ELF Note corrupted ! > Cannot determine the file type of vmlinux > > To fix this issue, after opening vmlinux file, make a call to > elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not > to touch the segment and section layout. It informs the library > that the application will take responsibility for the layout of the > file and that the library should not insert any padding between > sections. > > 2. Fix can't find starting instruction warnings when run on vmlinux > > Objtool throws a lot of can't find starting instruction warnings > when run on vmlinux with --ftr-fixup option. > > These warnings are seen because find_insn() function looks for > instructions at offsets that are relative to the start of the section. > In case of individual object files (.o), there are no can't find > starting instruction warnings seen because the actual offset > associated with an instruction is itself a relative offset since the > sections start at offset 0x0. > > However, in case of vmlinux, find_insn() function fails to find > instructions at the actual offset associated with an instruction > since the sections in vmlinux do not start at offset 0x0. Due to > this, find_insn() will look for absolute offset and not the relative > offset. This is resulting in a lot of can't find starting instruction > warnings when objtool is run on vmlinux. > > To fix this, pass offset that is relative to the start of the section > to find_insn(). > > find_insn() is also looking for symbols of size 0. But, objtool does > not store empty STT_NOTYPE symbols in the rbtree. Due to this, > for empty symbols, objtool is throwing can't find starting > instruction warnings. Fix this by ignoring symbols that are of > size 0 since objtool does not add them to the rbtree. > > 3. Objtool is throwing unannotated intra-function call warnings > when run on vmlinux with --ftr-fixup option. > > One such example: > > vmlinux: warning: objtool: .text+0x3d94: > unannotated intra-function call > > .text + 0x3d94 = c0008000 + 3d94 = c00081d4 > > c00081d4: 45 24 02 48 bl c002a618 > > > c002a610 : > c002a610: 0e 01 4c 3c addis r2,r12,270 > c002a610: R_PPC64_REL16_HA.TOC. > c002a614: f0 6c 42 38 addir2,r2,27888 > c002a614: R_PPC64_REL16_LO.TOC.+0x4 > c002a618: a6 02 08 7c mflrr0 > > This is happening because we should be looking for destination > symbols that are at absolute offsets instead of relative offsets. > After fixing dest_off to point to absolute offset, there are still > a lot of these warnings shown. > > In the above example, objtool is computing the destination > offset to be c002a618, which points to a completely > different instruction. find_call_destination() is looking for this > offset and failing. Instead, we should be looking for destination > offset c002a610 which points to system_reset_exception > function. > > Even after fixing the way destination offset is computed, and > after looking for dest_off - 0x8 in cases where the original offset > is not found, there are still a lot of unannotated intra-function > call warnings generated. This is due to symbols that are not > properly annotated. > > So, for now, as a hack to curb these warnings, do not emit > unannotated intra-function call warnings when objtool is run > with --ftr-fixup option. > > TODO: > This patch enables build time feature fixup only for powerpc little > endian configs. There are boot failures with big endian configs. > Posting this as an initial RFC to get some review comments while I work > on big endian issues. > > [1] > https://lore.kernel.org/linuxppc-dev/20170521010130.13552-1-npig...@gmail.com/ > > Co-developed-by: Nicholas Piggin > Signed-off-by: Nicholas Piggin > Signed-off-by: Sathvika Vasireddy When I build this series with LLVM 14 [1] (due to an issue I report below), I am getting a crash when CONFIG_FTR_FIXUP_SELFTEST is disabled. diff --git a/arch/powerpc/configs/ppc64_defconfig
[RFC PATCH 2/2] objtool/powerpc: Enhance objtool to fixup alternate feature relative addresses
Implement build-time fixup of alternate feature relative addresses for the out-of-line (else) patch code. Initial posting to achieve the same using another tool can be found at [1]. Idea is to implement this using objtool instead of introducing another tool since it already has elf parsing and processing covered. Introduce --ftr-fixup as an option to objtool to do feature fixup at build-time. Couple of issues and warnings encountered while implementing feature fixup using objtool are as follows: 1. libelf is creating corrupted vmlinux file after writing necessary changes to the file. Due to this, kexec is not able to load new kernel. It gives the following error: ELF Note corrupted ! Cannot determine the file type of vmlinux To fix this issue, after opening vmlinux file, make a call to elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not to touch the segment and section layout. It informs the library that the application will take responsibility for the layout of the file and that the library should not insert any padding between sections. 2. Fix can't find starting instruction warnings when run on vmlinux Objtool throws a lot of can't find starting instruction warnings when run on vmlinux with --ftr-fixup option. These warnings are seen because find_insn() function looks for instructions at offsets that are relative to the start of the section. In case of individual object files (.o), there are no can't find starting instruction warnings seen because the actual offset associated with an instruction is itself a relative offset since the sections start at offset 0x0. However, in case of vmlinux, find_insn() function fails to find instructions at the actual offset associated with an instruction since the sections in vmlinux do not start at offset 0x0. Due to this, find_insn() will look for absolute offset and not the relative offset. This is resulting in a lot of can't find starting instruction warnings when objtool is run on vmlinux. To fix this, pass offset that is relative to the start of the section to find_insn(). find_insn() is also looking for symbols of size 0. But, objtool does not store empty STT_NOTYPE symbols in the rbtree. Due to this, for empty symbols, objtool is throwing can't find starting instruction warnings. Fix this by ignoring symbols that are of size 0 since objtool does not add them to the rbtree. 3. Objtool is throwing unannotated intra-function call warnings when run on vmlinux with --ftr-fixup option. One such example: vmlinux: warning: objtool: .text+0x3d94: unannotated intra-function call .text + 0x3d94 = c0008000 + 3d94 = c00081d4 c00081d4: 45 24 02 48 bl c002a618 c002a610 : c002a610: 0e 01 4c 3c addis r2,r12,270 c002a610: R_PPC64_REL16_HA.TOC. c002a614: f0 6c 42 38 addir2,r2,27888 c002a614: R_PPC64_REL16_LO.TOC.+0x4 c002a618: a6 02 08 7c mflrr0 This is happening because we should be looking for destination symbols that are at absolute offsets instead of relative offsets. After fixing dest_off to point to absolute offset, there are still a lot of these warnings shown. In the above example, objtool is computing the destination offset to be c002a618, which points to a completely different instruction. find_call_destination() is looking for this offset and failing. Instead, we should be looking for destination offset c002a610 which points to system_reset_exception function. Even after fixing the way destination offset is computed, and after looking for dest_off - 0x8 in cases where the original offset is not found, there are still a lot of unannotated intra-function call warnings generated. This is due to symbols that are not properly annotated. So, for now, as a hack to curb these warnings, do not emit unannotated intra-function call warnings when objtool is run with --ftr-fixup option. TODO: This patch enables build time feature fixup only for powerpc little endian configs. There are boot failures with big endian configs. Posting this as an initial RFC to get some review comments while I work on big endian issues. [1] https://lore.kernel.org/linuxppc-dev/20170521010130.13552-1-npig...@gmail.com/ Co-developed-by: Nicholas Piggin Signed-off-by: Nicholas Piggin Signed-off-by: Sathvika Vasireddy --- arch/Kconfig | 3 + arch/powerpc/Kconfig | 5 + arch/powerpc/Makefile | 5 + arch/powerpc/include/asm/feature-fixups.h | 11 +- arch/powerpc/kernel/vmlinux.lds.S | 14 +- arch/powerpc/lib/feature-fixups.c | 13 + scripts/Makefile.lib | 7 + scripts/Makefile.vmlinux | 15 +- tools/objtool/arch/powerpc/special.c | 329 ++ tools/objtool/arch/x86/special.c
