Re: [PATCH v3 14/21] objtool: Prevent kCFI hashes from being decoded as instructions
Josh Poimboeuf <[email protected]>
| Newsgroups | org.kernel.vger.live-patching,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <rvazkws6uosluw7lxjpf3pmxzhmktmxehj6momrjqpe6nuej3z@h6ip4ikjiwfo> |
On Fri, May 15, 2026 at 12:16:51AM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: > - [High] Build failure due to undeclared mapping symbol functions. > - [Low] Unused header inclusion. > -- > > commit 4ad78a24a64cd6a2d10b9a2f9c0d306fba3e6d19 > Author: Josh Poimboeuf <[email protected]> > > objtool: Prevent kCFI hashes from being decoded as instructions > > On arm64 with CONFIG_CFI=y, Clang places a 4-byte kCFI type hash immediately > before each address-taken function entry. This commit uses mapping symbols > to mark such data as NOP in text sections to prevent objtool from decoding > them. > > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > > index e05dc7a93dc1e..2b03a2d6fc952 100644 > > --- a/tools/objtool/check.c > > +++ b/tools/objtool/check.c > > @@ -25,6 +25,7 @@ > > #include <linux/kernel.h> > > #include <linux/static_call_types.h> > > #include <linux/string.h> > > +#include <linux/kconfig.h> > > This isn't a bug, but is this include needed? It doesn't appear that any > Kconfig configuration macros are being used in the modified code. Fixed. > > [ ... ] > > > @@ -478,6 +483,16 @@ static int decode_instructions(struct objtool_file *file) > > > > prev_len = insn->len; > > > > + /* Use mapping symbols to skip data in text sections */ > > + sec_for_each_sym_from(sec, map_sym) { > > + if (map_sym->offset > offset) > > + break; > > + if (is_mapping_sym(map_sym)) > > + is_data = is_data_mapping_sym(map_sym); > > Could this cause a build failure across architectures here? It appears > is_mapping_sym() and is_data_mapping_sym() are neither declared nor defined > anywhere in the codebase at this point in the patch series. > > If these functions are only introduced in a subsequent commit, applying > this patch independently might result in an implicit declaration of function > error, breaking git bisectability. Fixes. -- Josh