linux-kernel - Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXE5uw4+zV3JVpfA2drOD5TZVMs5a_E5wrrnzjEYc=E_fA@mail.gmail.com>
Date:   Thu, 28 Jan 2021 22:03:30 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Nathan Chancellor <natechancellor@...il.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL

On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> Clang's integrated assembler only accepts UAL syntax, rewrite the
> instructions that were changed by RVCTv2.1.
>
> The document "Assembly language changes after RVCTv2.1" was very
> helpful.
>
> This exposed a bug in Clang's integrated assembler, which hopefully will
> land in clang-12, but is required to test this patch with LLVM_IAS=1.
>
> Link: https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/assembly-language-changes-after-rvctv2-1
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Link: https://reviews.llvm.org/D95586
> Reported-by: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Nick Desaulniers <ndesaulniers@...gle.com>
> ---
> * Fix additonal swpvsb case in test-arm.c when __LINUX_ARM_ARCH__ < 6,
>   reported by Arnd.
> * Fix arch/arm/probes/kprobes/test-thumb.c, reported by Arnd.
> * Modify the oneline to note I'm modifying test-*.c.
>
>  arch/arm/probes/kprobes/test-arm.c   | 290 +++++++++++++--------------
>  arch/arm/probes/kprobes/test-thumb.c |  20 +-
>  2 files changed, 155 insertions(+), 155 deletions(-)
>
...
> diff --git a/arch/arm/probes/kprobes/test-thumb.c b/arch/arm/probes/kprobes/test-thumb.c
> index 456c181a7bfe..63277c1006b9 100644
> --- a/arch/arm/probes/kprobes/test-thumb.c
> +++ b/arch/arm/probes/kprobes/test-thumb.c
> @@ -441,21 +441,21 @@ void kprobe_thumb32_test_cases(void)
>                 "3:     mvn     r0, r0  \n\t"
>                 "2:     nop             \n\t")
>
> -       TEST_RX("tbh    [pc, r",7, (9f-(1f+4))>>1,"]",
> +       TEST_RX("tbh    [pc, r",7, (9f-(1f+4))>>1,", lsl #1]",

Why is this change needed? Are the resulting opcodes equivalent? Does
GAS infer the lsl #1 but Clang doesn't?

>                 "9:                     \n\t"
>                 ".short (2f-1b-4)>>1    \n\t"
>                 ".short (3f-1b-4)>>1    \n\t"
>                 "3:     mvn     r0, r0  \n\t"
>                 "2:     nop             \n\t")
>
> -       TEST_RX("tbh    [pc, r",12, ((9f-(1f+4))>>1)+1,"]",
> +       TEST_RX("tbh    [pc, r",12, ((9f-(1f+4))>>1)+1,", lsl #1]",
>                 "9:                     \n\t"
>                 ".short (2f-1b-4)>>1    \n\t"
>                 ".short (3f-1b-4)>>1    \n\t"
>                 "3:     mvn     r0, r0  \n\t"
>                 "2:     nop             \n\t")
>
> -       TEST_RRX("tbh   [r",1,9f, ", r",14,1,"]",
> +       TEST_RRX("tbh   [r",1,9f, ", r",14,1,", lsl #1]",
>                 "9:                     \n\t"
>                 ".short (2f-1b-4)>>1    \n\t"
>                 ".short (3f-1b-4)>>1    \n\t"
> @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
>
>         TEST_UNSUPPORTED("strexb        r0, r1, [r2]")
>         TEST_UNSUPPORTED("strexh        r0, r1, [r2]")
> -       TEST_UNSUPPORTED("strexd        r0, r1, [r2]")
> +       TEST_UNSUPPORTED("strexd        r0, r1, r2, [r2]")
>         TEST_UNSUPPORTED("ldrexb        r0, [r1]")
>         TEST_UNSUPPORTED("ldrexh        r0, [r1]")
> -       TEST_UNSUPPORTED("ldrexd        r0, [r1]")
> +       TEST_UNSUPPORTED("ldrexd        r0, r1, [r1]")
>
>         TEST_GROUP("Data-processing (shifted register) and (modified immediate)")
>
>  #define _DATA_PROCESSING32_DNM(op,s,val)                                       \
> -       TEST_RR(op s".w r0,  r",1, VAL1,", r",2, val, "")                       \
> +       TEST_RR(op s"   r0,  r",1, VAL1,", r",2, val, "")                       \

What is wrong with these .w suffixes? Shouldn't the assembler accept
these even on instructions that only exist in a wide encoding?

>         TEST_RR(op s"   r1,  r",1, VAL1,", r",2, val, ", lsl #3")               \
>         TEST_RR(op s"   r2,  r",3, VAL1,", r",2, val, ", lsr #4")               \
>         TEST_RR(op s"   r3,  r",3, VAL1,", r",2, val, ", asr #5")               \
> @@ -764,7 +764,7 @@ CONDITION_INSTRUCTIONS(22,
>         TEST("nop.w")
>         TEST("wfi.w")
>         TEST_SUPPORTED("wfe.w")
> -       TEST_UNSUPPORTED("dbg.w #0")
> +       TEST_UNSUPPORTED("dbg   #0")
>
>         TEST_UNSUPPORTED("clrex")
>         TEST_UNSUPPORTED("dsb")
> @@ -790,9 +790,9 @@ CONDITION_INSTRUCTIONS(22,
>         TEST_BB(  "b.w  2b")
>         TEST_BF_X("b.w  2f", SPACE_0x1000)
>
> -       TEST_BF(  "bl.w 2f")
> -       TEST_BB(  "bl.w 2b")
> -       TEST_BB_X("bl.w 2b", SPACE_0x1000)
> +       TEST_BF(  "bl   2f")
> +       TEST_BB(  "bl   2b")
> +       TEST_BB_X("bl   2b", SPACE_0x1000)
>
>         TEST_X( "blx    __dummy_arm_subroutine",
>                 ".arm                           \n\t"
> --
> 2.30.0.365.g02bc693789-goog
>