linux-kernel - Re: [PATCH v3 1/5] arm64: vdso32: Introduce COMPAT_CC_IS

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]

Date:   Tue, 1 Oct 2019 14:14:23 +0100
From:   Will Deacon <will@...nel.org>
To:     Vincenzo Frascino <vincenzo.frascino@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        ard.biesheuvel@...aro.org, ndesaulniers@...gle.com,
        catalin.marinas@....com, tglx@...utronix.de
Subject: Re: [PATCH v3 1/5] arm64: vdso32: Introduce COMPAT_CC_IS_GCC

On Thu, Sep 26, 2019 at 10:43:38PM +0100, Vincenzo Frascino wrote:
> As reported by Will Deacon the .config file and the generated
> include/config/auto.conf can end up out of sync after a set of
> commands since CONFIG_CROSS_COMPILE_COMPAT_VDSO is not updated
> correctly.
> 
> The sequence can be reproduced as follows:
> 
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> [...]
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig
> [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"]
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> 
> Which results in:
> 
> arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty,
> the compat vDSO will not be built
> 
> even though the compat vDSO has been built:
> 
> $ file arch/arm64/kernel/vdso32/vdso.so
> arch/arm64/kernel/vdso32/vdso.so: ELF 32-bit LSB pie executable, ARM,
> EABI5 version 1 (SYSV), dynamically linked,
> BuildID[sha1]=c67f6c786f2d2d6f86c71f708595594aa25247f6, stripped
> 
> A similar case that involves changing the configuration parameter multiple
> times can be reconducted to the same family of problems.
> 
> The reason behind it comes from the fact that the master Makefile includes
> that architecture Makefile twice, once before the syncconfig and one after.
> Since the synchronization of the files happens only upon syncconfig, the
> architecture Makefile included before this event does not see the change in
> configuration.
> 
> As a consequence of this it is not possible to handle the cross compiler
> definitions inside the architecture Makefile.
> 
> Address the problem removing CONFIG_CROSS_COMPILE_COMPAT_VDSO and moving
> the detection of the correct compiler into Kconfig via COMPAT_CC_IS_GCC.
> 
> As a consequence of this it is not possible anymore to set the compat
> cross compiler from menuconfig but it requires to be exported via
> command line.
> 
> E.g.:
> 
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> CROSS_COMPILE_COMPAT=arm-linux-gnueabihf
> 
> Cc: Will Deacon <will@...nel.org>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@....com>
> ---
>  arch/arm64/Kconfig                |  5 ++++-
>  arch/arm64/Makefile               | 18 +++++-------------
>  arch/arm64/kernel/vdso32/Makefile |  2 --
>  3 files changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 37c610963eee..0e5beb928af5 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -110,7 +110,7 @@ config ARM64
>  	select GENERIC_STRNLEN_USER
>  	select GENERIC_TIME_VSYSCALL
>  	select GENERIC_GETTIMEOFDAY
> -	select GENERIC_COMPAT_VDSO if (!CPU_BIG_ENDIAN && COMPAT)
> +	select GENERIC_COMPAT_VDSO if (!CPU_BIG_ENDIAN && COMPAT && COMPATCC_IS_ARM_GCC)
>  	select HANDLE_DOMAIN_IRQ
>  	select HARDIRQS_SW_RESEND
>  	select HAVE_PCI
> @@ -313,6 +313,9 @@ config KASAN_SHADOW_OFFSET
>  	default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
>  	default 0xffffffffffffffff
>  
> +config COMPATCC_IS_ARM_GCC
> +	def_bool $(success,$(COMPATCC) --version | head -n 1 | grep -q "arm-.*-gcc")

I've seen toolchains where the first part of the tuple is "armv7-", so they
won't get detected here. However, do we really need to detect this? If
somebody passes a duff compiler, then the build will fail in the same way as
if they passed it to CROSS_COMPILE=.

I'd prefer to drop this check altogether.

Will