From: Mark Rutland <mark.rutland@arm.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Nathan Chancellor <nathan@kernel.org>, x86-ml <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: clang memcpy calls
Date: Thu, 24 Mar 2022 15:29:56 +0000 [thread overview]
Message-ID: <YjyOdJlda3JcK3he@lakrids> (raw)
In-Reply-To: <YjxTt3pFIcV3lt8I@zn.tnic>
On Thu, Mar 24, 2022 at 12:19:19PM +0100, Borislav Petkov wrote:
> Hi folks,
Hi Boris,
> so I've been looking at a recent objtool noinstr warning from clang
> builds:
>
> vmlinux.o: warning: objtool: sync_regs()+0x20: call to memcpy() leaves .noinstr.text section
>
> The issue is that clang generates a memcpy() call when a struct copy
> happens:
>
> if (regs != eregs)
> *regs = *eregs;
>
> see below for asm output.
>
> While gcc does simply generate an actual "rep; movsq".
I think there's a more general soundness problem with noinstr here,
because with the options we pass today it's entirely legitimate for the
compiler to generate out-of-line calls to a number of support functions
(e.g. memcpy, but also memset and others), and we either need to inhibit
out-of-line calls to *any* of those, or ensure the out-of-line copies
used are never instrumented.
I'm not entirely sure how to prevent this on arm64 short of some
whole-compilation-unit shennanigans -- we don't have short sequence like
"rep movsq" that can be easily inlined, and we explicitly instrument
mem*() when certain KASAN options are selected.
I think we need more compiler help to make noinstr sound generally,
and/or may need to rethink the way we use noinstr.
Thanks,
Mark.
> So, how hard would it be to make clang do that too pls?
>
> Oh, and another thing while we're comparing asm: I'd love for clang's
> -fverbose-asm to issue interleaved C source lines too, like gcc does.
>
> That's it - no pink pony - just "normal" wishes. :-)
>
> GCC:
> ====
>
> sync_regs:
> .LASANPC4246:
> # arch/x86/kernel/traps.c:770: {
> movq %rdi, %rsi # tmp91, eregs
> # arch/x86/kernel/traps.c:771: struct pt_regs *regs = (struct pt_regs *)this_cpu_read(cpu_current_top_of_stack) - 1;
> #APP
> # 771 "arch/x86/kernel/traps.c" 1
> movq %gs:cpu_current_top_of_stack(%rip), %rax # cpu_current_top_of_stack, pfo_val__
> # 0 "" 2
> # arch/x86/kernel/traps.c:771: struct pt_regs *regs = (struct pt_regs *)this_cpu_read(cpu_current_top_of_stack) - 1;
> #NO_APP
> subq $168, %rax #, <retval>
> # arch/x86/kernel/traps.c:772: if (regs != eregs)
> cmpq %rdi, %rax # eregs, <retval>
> je .L387 #,
> # arch/x86/kernel/traps.c:773: *regs = *eregs;
> movl $21, %ecx #, tmp89
> movq %rax, %rdi # <retval>, <retval>
> rep movsq
> .L387:
> # arch/x86/kernel/traps.c:775: }
> ret
>
> CLANG:
> ======
>
> .section .noinstr.text,"ax",@progbits
> .globl sync_regs # -- Begin function sync_regs
> .p2align 6, 0x90
> .type sync_regs,@function
> sync_regs: # @sync_regs
> # %bb.0: # %entry
> pushq %rbx
> #APP
> movq %gs:cpu_current_top_of_stack(%rip), %rbx
> #NO_APP
> addq $-168, %rbx
> cmpq %rdi, %rbx
> je .LBB19_2
> # %bb.1: # %if.then
> movq %rdi, %rsi
> movl $168, %edx
> movq %rbx, %rdi
> callq memcpy@PLT
> .LBB19_2: # %if.end
> movq %rbx, %rax
> popq %rbx
> retq
>
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-03-24 15:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 11:19 clang memcpy calls Borislav Petkov
2022-03-24 15:29 ` Mark Rutland [this message]
2022-03-24 18:43 ` Nick Desaulniers
2022-03-24 22:54 ` David Laight
2022-03-25 12:15 ` Mark Rutland
2022-03-25 14:13 ` Peter Zijlstra
2022-03-25 15:12 ` Segher Boessenkool
2022-03-28 9:52 ` Mark Rutland
2022-03-28 10:20 ` Jakub Jelinek
2022-03-28 11:54 ` Peter Zijlstra
2022-03-28 12:55 ` Mark Rutland
2022-03-28 13:12 ` Jakub Jelinek
2022-03-28 13:44 ` Mark Rutland
2022-03-30 14:45 ` Marco Elver
2022-03-28 14:22 ` Segher Boessenkool
2022-03-28 14:58 ` Mark Rutland
2022-03-28 15:59 ` Segher Boessenkool
2022-03-28 16:16 ` Peter Zijlstra
2022-03-28 16:58 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YjyOdJlda3JcK3he@lakrids \
--to=mark.rutland@arm.com \
--cc=bp@alien8.de \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.