linux-kernel - Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR

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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrA5f44hySky8v5g@FVFF77S0Q05N>
Date:   Mon, 20 Jun 2022 10:10:23 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Tong Tiangen <tongtiangen@...wei.com>
Cc:     James Morse <james.morse@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Robin Murphy <robin.murphy@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>, linuxppc-dev@...ts.ozlabs.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Kefeng Wang <wangkefeng.wang@...wei.com>,
        Xie XiuQi <xiexiuqi@...wei.com>,
        Guohanjun <guohanjun@...wei.com>
Subject: Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use
 extable type EX_TYPE_UACCESS_ERR_ZERO

On Mon, Jun 20, 2022 at 10:59:12AM +0800, Tong Tiangen wrote:
> 在 2022/6/18 20:40, Mark Rutland 写道:
> > On Sat, Jun 18, 2022 at 04:42:06PM +0800, Tong Tiangen wrote:
> > > > > > diff --git a/arch/arm64/include/asm/asm-extable.h
> > > > > > b/arch/arm64/include/asm/asm-extable.h
> > > > > > index 56ebe183e78b..9c94ac1f082c 100644
> > > > > > --- a/arch/arm64/include/asm/asm-extable.h
> > > > > > +++ b/arch/arm64/include/asm/asm-extable.h
> > > > > > @@ -28,6 +28,14 @@
> > > > > >        __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0)
> > > > > >        .endm
> > > > > > +/*
> > > > > > + * Create an exception table entry for uaccess `insn`, which
> > > > > > will branch to `fixup`
> > > > > > + * when an unhandled fault is taken.
> > > > > > + * ex->data = ~0 means both reg_err and reg_zero is set to wzr(x31).
> > > > > > + */
> > > > > > +    .macro          _asm_extable_uaccess, insn, fixup
> > > > > > +    __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_UACCESS_ERR_ZERO, ~0)
> > > > > > +    .endm
> > > > > 
> > > > > I'm not too keen on using `~0` here, since that also sets other bits
> > > > > in the
> > > > > data field, and its somewhat opaque.
> > > > > 
> > > > > How painful is it to generate the data fields as with the C version
> > > > > of this
> > > > > macro, so that we can pass in wzr explciitly for the two sub-fields?
> > > > > 
> > > > > Other than that, this looks good to me.
> > > > > 
> > > > > Thanks,
> > > > > Mark.
> > > > 
> > > > ok, will fix next version.
> > > > 
> > > > Thanks,
> > > > Tong.
> > > 
> > > I tried to using data filelds as with C version, but here assembly code we
> > > can not using operator such as << and |, if we use lsl and orr instructions,
> > > the gpr will be occupied.
> > > 
> > > So how about using 0x3ff directly here? it means err register and zero
> > > register both set to x31.
> > 
> > I had a go at implementing this, and it seems simple enough. Please see:
> > 
> >    https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/extable/asm-uaccess
> > 
> 
> I made the following modifications, and the other parts are based on your
> implementation:
> 
> arch/arm64/include/asm/asm-extable.h
> [...]
> .macro          _asm_extable_uaccess, insn, fixup
> _ASM_EXTABLE_UACCESS(\insn, \fixup)
> .endm
> [...]

I also made this same change locally when testing, and building with GCC 11.1.0
or LLVM 14.0.0 I am not seeing any problem when building, and the result is as
expected:

| [mark@...rids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- defconfig
| *** Default configuration is based on 'defconfig'
| #
| # No change to .config
| #
| [mark@...rids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j50 arch/arm64/lib/
|   CALL    scripts/atomic/check-atomics.sh
|   CC      arch/arm64/kernel/asm-offsets.s
|   CALL    scripts/checksyscalls.sh
|   AS      arch/arm64/kernel/vdso/note.o
|   AS      arch/arm64/kernel/vdso/sigreturn.o
|   LD      arch/arm64/kernel/vdso/vdso.so.dbg
|   VDSOSYM include/generated/vdso-offsets.h
|   OBJCOPY arch/arm64/kernel/vdso/vdso.so
| make[2]: Nothing to be done for 'arch/arm64/lib/'.
|   AS      arch/arm64/lib/clear_page.o
|   AS      arch/arm64/lib/clear_user.o
|   AS      arch/arm64/lib/copy_from_user.o
|   AS      arch/arm64/lib/copy_page.o
|   AS      arch/arm64/lib/copy_to_user.o
|   CC      arch/arm64/lib/csum.o
|   CC      arch/arm64/lib/delay.o
|   AS      arch/arm64/lib/memchr.o
|   AS      arch/arm64/lib/memcmp.o
|   AS      arch/arm64/lib/memcpy.o
|   AS      arch/arm64/lib/memset.o
|   AS      arch/arm64/lib/strchr.o
|   AS      arch/arm64/lib/strcmp.o
|   AS      arch/arm64/lib/strlen.o
|   AS      arch/arm64/lib/strncmp.o
|   AS      arch/arm64/lib/strnlen.o
|   AS      arch/arm64/lib/strrchr.o
|   AS      arch/arm64/lib/tishift.o
|   AS      arch/arm64/lib/crc32.o
|   AS      arch/arm64/lib/mte.o
|   CC [M]  arch/arm64/lib/xor-neon.o
|   AR      arch/arm64/lib/built-in.a
|   AR      arch/arm64/lib/lib.a
| [mark@...rids:~/src/linux]% usekorg 12.1.0 aarch64-linux-objdump -j __ex_table -D arch/arm64/lib/clear_user.o
| 
| arch/arm64/lib/clear_user.o:     file format elf64-littleaarch64
| 
| 
| Disassembly of section __ex_table:
| 
| 0000000000000000 <__ex_table>:
|         ...
|    8:   03ff0003        .inst   0x03ff0003 ; undefined
|         ...
|   14:   03ff0003        .inst   0x03ff0003 ; undefined
|         ...
|   20:   03ff0003        .inst   0x03ff0003 ; undefined
|         ...
|   2c:   03ff0003        .inst   0x03ff0003 ; undefined
|         ...
|   38:   03ff0003        .inst   0x03ff0003 ; undefined
|         ...
|   44:   03ff0003        .inst   0x03ff0003 ; undefined

> The following errors are reported during compilation:
> [...]
> arch/arm64/lib/clear_user.S:45: Error: invalid operands (*ABS* and *UND*
> sections) for `<<'
> [...]

As above, I'm not seeing this.

This suggests that the EX_DATA_REG() macro is going wrong somehow. Assuming the
operand types correspond to the LHS and RHS of the expression, this would mean
the GPR number is defined, but the REG value is not, and I can't currently see
how that can happen.

> "<<" is invalid operands in assembly, is there something wrong with me?

At the moment I can only assume there is a local problem. I'd suspect a typo
somewhere, but maybe you have a toolchain which behaves differently?

Thanks,
Mark.