Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool: bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction with modified stack frame
It's likely that this is the complete set at the moment, I saw each one multiple times, but did not see any others. I'll reply with the respective object files for your reference, in case these are so far unknown to you. There are only a handful of randconfig warnings we see overall in the kernel these days (at least on x86 and arm64), so even if they are false-positive, it would be great to get rid of the output so we can do randconfig testing on 4.14.y and treat any output from 'make -s' as a regression. I did not check
With gcc-8, things are looking very differently, and we still get an endless supply of similar warnings.
Arnd
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool: bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction with modified stack frame
It's likely that this is the complete set at the moment, I saw each one multiple times, but did not see any others. I'll reply with the respective object files for your reference, in case these are so far unknown to you. There are only a handful of randconfig warnings we see overall in the kernel these days (at least on x86 and arm64), so even if they are false-positive, it would be great to get rid of the output so we can do randconfig testing on 4.14.y and treat any output from 'make -s' as a regression. I did not check
The third one has been fixed upstream with
99ce7962d52d ("objtool: Fix switch-table detection")
... so we should put that one into stable.
I don't recall seeing the other two, I'll look into them.
With gcc-8, things are looking very differently, and we still get an endless supply of similar warnings.
Yeah, I haven't forgotten about GCC 8, it just fell off my plate thanks to spectre/meltdown. It's still on my TODO list...
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
While this is probably an objtool bug, the code is very odd:
00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>: 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5> 1a9: R_X86_64_PC32 __fentry__-0x4 1ad: 55 push %rbp 1ae: 48 89 e5 mov %rsp,%rbp 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1b5: 48 83 ec 20 sub $0x20,%rsp 1b9: 48 89 ec mov %rbp,%rsp 1bc: 5d pop %rbp 1bd: c3 retq
The function just allocates/aligns its stack space and then returns. It seems like GCC was too smart for its own good here, as the function doesn't test what it's supposed to. Can you share the config for this one?
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
From a quick glance, this looks like yet another switch statement
detection issue. I'll need to dig into it more (unless PeterZ, my shiny new co-maintainer, wants to take a look!)
+Kees
On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
While this is probably an objtool bug, the code is very odd:
00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>: 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5> 1a9: R_X86_64_PC32 __fentry__-0x4 1ad: 55 push %rbp 1ae: 48 89 e5 mov %rsp,%rbp 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1b5: 48 83 ec 20 sub $0x20,%rsp 1b9: 48 89 ec mov %rbp,%rsp 1bc: 5d pop %rbp 1bd: c3 retq
The function just allocates/aligns its stack space and then returns. It seems like GCC was too smart for its own good here, as the function doesn't test what it's supposed to. Can you share the config for this one?
lkdtm is a "interesting" module in that it tries to do bad things to test for various stuff. Kees, does the above look like it is doing the correct thing?
thanks,
greg k-h
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
While this is probably an objtool bug, the code is very odd:
00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>: 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5> 1a9: R_X86_64_PC32 __fentry__-0x4 1ad: 55 push %rbp 1ae: 48 89 e5 mov %rsp,%rbp 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1b5: 48 83 ec 20 sub $0x20,%rsp 1b9: 48 89 ec mov %rbp,%rsp 1bc: 5d pop %rbp 1bd: c3 retq
The function just allocates/aligns its stack space and then returns. It seems like GCC was too smart for its own good here, as the function doesn't test what it's supposed to.
AFAIU, there is an optimization step in gcc that eliminates basic blocks that contain an unconditional NULL pointer dereference, based on the assumption that it's undefined behavior, and if we ever get here, it is free to drop not only code after but also before it as long as it doesn't have any side-effects.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Can you share the config for this one?
Arnd
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
While this is probably an objtool bug, the code is very odd:
00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>: 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5> 1a9: R_X86_64_PC32 __fentry__-0x4 1ad: 55 push %rbp 1ae: 48 89 e5 mov %rsp,%rbp 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1b5: 48 83 ec 20 sub $0x20,%rsp 1b9: 48 89 ec mov %rbp,%rsp 1bc: 5d pop %rbp 1bd: c3 retq
The function just allocates/aligns its stack space and then returns. It seems like GCC was too smart for its own good here, as the function doesn't test what it's supposed to.
AFAIU, there is an optimization step in gcc that eliminates basic blocks that contain an unconditional NULL pointer dereference, based on the assumption that it's undefined behavior, and if we ever get here, it is free to drop not only code after but also before it as long as it doesn't have any side-effects.
Ok, I expected something like that. GCC "undefined behavior" strikes again.
Kees, I suppose you'll need to obfuscate the code to stay one step ahead of GCC.
While this may be an objtool bug, I might not fix it because it served a useful purpose here in finding GCC crap.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Can you share the config for this one?
Would be interesting to analyze that config to understand what options are causing GCC to do that. I don't see this "optimization" with my config.
On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Ok, I expected something like that. GCC "undefined behavior" strikes again.
Kees, I suppose you'll need to obfuscate the code to stay one step ahead of GCC.
While this may be an objtool bug, I might not fix it because it served a useful purpose here in finding GCC crap.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Can you share the config for this one?
Would be interesting to analyze that config to understand what options are causing GCC to do that. I don't see this "optimization" with my config.
This seems like a very rare combination, the flags I need to reproduce are "gcc -O2 -mno-red-zone -mpreferred-stack-boundary=3 -march=nocona", however I do see the same behavior with every gcc version since 4.8!
Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl show this, but none of the modern microarchitectures do.
Arnd
On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Ok, I expected something like that. GCC "undefined behavior" strikes again.
Kees, I suppose you'll need to obfuscate the code to stay one step ahead of GCC.
While this may be an objtool bug, I might not fix it because it served a useful purpose here in finding GCC crap.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Uuhhh... I don't see the NULL deref, and even if it was eliminating later stuff, I'd still expect a pr_info() ...
void lkdtm_CORRUPT_LIST_ADD(void) { /* * Initially, an empty list via LIST_HEAD: * test_head.next = &test_head * test_head.prev = &test_head */ LIST_HEAD(test_head); struct lkdtm_list good, bad; void *target[2] = { }; void *redirection = ⌖
pr_info("attempting good list addition\n"); ...
Can you share the config for this one?
Would be interesting to analyze that config to understand what options are causing GCC to do that. I don't see this "optimization" with my config.
This seems like a very rare combination, the flags I need to reproduce are "gcc -O2 -mno-red-zone -mpreferred-stack-boundary=3 -march=nocona", however I do see the same behavior with every gcc version since 4.8!
Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl show this, but none of the modern microarchitectures do.
I'll see if I can reproduce this...
-Kees
On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook keescook@chromium.org wrote:
On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Ok, I expected something like that. GCC "undefined behavior" strikes again.
Kees, I suppose you'll need to obfuscate the code to stay one step ahead of GCC.
While this may be an objtool bug, I might not fix it because it served a useful purpose here in finding GCC crap.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Uuhhh... I don't see the NULL deref, and even if it was eliminating later stuff, I'd still expect a pr_info() ...
void lkdtm_CORRUPT_LIST_ADD(void) { /* * Initially, an empty list via LIST_HEAD: * test_head.next = &test_head * test_head.prev = &test_head */ LIST_HEAD(test_head); struct lkdtm_list good, bad; void *target[2] = { }; void *redirection = ⌖
pr_info("attempting good list addition\n");...
Can you share the config for this one?
Would be interesting to analyze that config to understand what options are causing GCC to do that. I don't see this "optimization" with my config.
This seems like a very rare combination, the flags I need to reproduce are "gcc -O2 -mno-red-zone -mpreferred-stack-boundary=3 -march=nocona", however I do see the same behavior with every gcc version since 4.8!
Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl show this, but none of the modern microarchitectures do.
I'll see if I can reproduce this...
To clarify, this is _only_ on 4.14, gcc 7.3.0, and any of march=nocona, bonnell, atom, silvermont, slm, or knl ?
Is it present in latest Linus and/or with gcc 8?
-Kees
On Fri, Feb 16, 2018 at 4:41 AM, Kees Cook keescook@chromium.org wrote:
On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook keescook@chromium.org wrote:
On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote: > On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Ok, I expected something like that. GCC "undefined behavior" strikes again.
Kees, I suppose you'll need to obfuscate the code to stay one step ahead of GCC.
While this may be an objtool bug, I might not fix it because it served a useful purpose here in finding GCC crap.
I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction.
Uuhhh... I don't see the NULL deref, and even if it was eliminating later stuff, I'd still expect a pr_info() ...
void lkdtm_CORRUPT_LIST_ADD(void) { /* * Initially, an empty list via LIST_HEAD: * test_head.next = &test_head * test_head.prev = &test_head */ LIST_HEAD(test_head); struct lkdtm_list good, bad; void *target[2] = { }; void *redirection = ⌖
pr_info("attempting good list addition\n");...
Can you share the config for this one?
Would be interesting to analyze that config to understand what options are causing GCC to do that. I don't see this "optimization" with my config.
This seems like a very rare combination, the flags I need to reproduce are "gcc -O2 -mno-red-zone -mpreferred-stack-boundary=3 -march=nocona", however I do see the same behavior with every gcc version since 4.8!
Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl show this, but none of the modern microarchitectures do.
I'll see if I can reproduce this...
To clarify, this is _only_ on 4.14, gcc 7.3.0, and any of march=nocona, bonnell, atom, silvermont, slm, or knl ?
Is it present in latest Linus and/or with gcc 8?
It is with all modern gcc versions: 4.8 though 8.0.1 on those -march values, and it still appears on latest Linus and next/master.
Arnd
On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
From a quick glance, this looks like yet another switch statement detection issue. I'll need to dig into it more (unless PeterZ, my shiny new co-maintainer, wants to take a look!)
Arnd, can you test this fix?
----
From: Josh Poimboeuf jpoimboe@redhat.com Subject: [PATCH] objtool: Another switch table detection fix
Continue the switch table detection whack-a-mole. Add a check to distinguish KASAN-related .rodata reads from switch-related .rodata reads in GCC 7.
This fixes the following warning:
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
Reported-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com --- tools/objtool/check.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 472e64e95891..46c1d239cc1b 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -925,7 +925,11 @@ static struct rela *find_switch_table(struct objtool_file *file, if (find_symbol_containing(file->rodata, text_rela->addend)) continue;
- return find_rela_by_dest(file->rodata, text_rela->addend); + rodata_rela = find_rela_by_dest(file->rodata, text_rela->addend); + if (!rodata_rela) + continue; + + return rodata_rela; }
return NULL;
On Wed, Feb 28, 2018 at 3:20 AM, Josh Poimboeuf jpoimboe@redhat.com wrote:
On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
From a quick glance, this looks like yet another switch statement detection issue. I'll need to dig into it more (unless PeterZ, my shiny new co-maintainer, wants to take a look!)
Arnd, can you test this fix?
It took me a while, as I had lost the earlier reproducer and am currently testing linux-next/gcc-8 whereas the report was for v4.14/gcc-7.
I have finally found a new reproducer on linux-next/gcc-7 and confirmed that the warning is fixed now, both for gcc-7 and gcc-8.
Thanks for the fix!
Arnd
On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool: lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool: bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction with modified stack frame
It's likely that this is the complete set at the moment, I saw each one multiple times, but did not see any others. I'll reply with the respective object files for your reference, in case these are so far unknown to you. There are only a handful of randconfig warnings we see overall in the kernel these days (at least on x86 and arm64), so even if they are false-positive, it would be great to get rid of the output so we can do randconfig testing on 4.14.y and treat any output from 'make -s' as a regression. I did not check
The third one has been fixed upstream with
99ce7962d52d ("objtool: Fix switch-table detection")
... so we should put that one into stable.
Now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Greg KH -
Josh Poimboeuf -
Kees Cook