linux-kernel - Re: [PATCH] MIPS: Support binutils configured with --enable-mips-fix-loongson3-llsc=yes

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: <alpine.LFD.2.21.2101091944330.1637534@eddie.linux-mips.org>
Date:   Sat, 9 Jan 2021 19:53:19 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Aurelien Jarno <aurelien@...el32.net>
cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        YunQiang Su <syq@...ian.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Huacai Chen <chenhuacai@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        "open list:MIPS" <linux-mips@...r.kernel.org>
Subject: Re: [PATCH] MIPS: Support binutils configured with
 --enable-mips-fix-loongson3-llsc=yes

On Sat, 9 Jan 2021, Aurelien Jarno wrote:

> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index cd4343edeb11..5ffdd67093bc 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -136,6 +136,25 @@ cflags-$(CONFIG_SB1XXX_CORELIS)	+= $(call cc-option,-mno-sched-prolog) \
>  #
>  cflags-y += -fno-stack-check
>  
> +# binutils from v2.35 when built with --enable-mips-fix-loongson3-llsc=yes,
> +# supports an -mfix-loongson3-llsc flag which emits a sync prior to each ll
> +# instruction to work around a CPU bug (see __SYNC_loongson3_war in asm/sync.h
> +# for a description).
> +#
> +# We disable this in order to prevent the assembler meddling with the
> +# instruction that labels refer to, ie. if we label an ll instruction:
> +#
> +# 1: ll v0, 0(a0)
> +#
> +# ...then with the assembler fix applied the label may actually point at a sync
> +# instruction inserted by the assembler, and if we were using the label in an
> +# exception table the table would no longer contain the address of the ll
> +# instruction.

 Interesting.  Given that a MIPS assembler is generally free to shuffle 
instructions as it sees fit in its default reorder mode as long as that 
does not change the semantics of the code executed, shouldn't we instead 
place all label/instruction pairs used for exception handling in noreorder 
blocks so as to make sure the label refers to the instruction an exception 
handler expects it to?

 E.g. for the case quoted above:

	.set	push
	.set	noreorder
1:	ll	v0, 0(a0)
	.set	pop

  Maciej