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: <20191001164657.l2wz3ghq6icm3lim@willie-the-truck>
Date:   Tue, 1 Oct 2019 17:46:58 +0100
From:   Will Deacon <will@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Vincenzo Frascino <vincenzo.frascino@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        ard.biesheuvel@...aro.org, ndesaulniers@...gle.com,
        tglx@...utronix.de
Subject: Re: [PATCH v3 1/5] arm64: vdso32: Introduce COMPAT_CC_IS_GCC

On Tue, Oct 01, 2019 at 04:30:56PM +0100, Catalin Marinas wrote:
> On Tue, Oct 01, 2019 at 03:43:54PM +0100, Will Deacon wrote:
> > > >>>> On Thu, Sep 26, 2019 at 10:43:38PM +0100, Vincenzo Frascino wrote:
> > > >>>>> +config COMPATCC_IS_ARM_GCC
> > > >>>>> +	def_bool $(success,$(COMPATCC) --version | head -n 1 | grep -q "arm-.*-gcc")
> [...]
> > My point was that we don't attempt to sanitise the compiler passed via
> > CROSS_COMPILE, so I don't think we should do anything special for COMPATCC
> > either.
> 
> What I really want from kbuild with this patch is:
> 
> 1. Not to warn me that I don't have a CROSS_COMPILE_COMPAT set
> 
> 2. Not to give me a compilation error if the makefile made up a COMPATCC
>    that doesn't work
> 
> Since we dropped the Kconfig option for the compat gcc prefix (which I
> didn't like anyway), COMPATCC is now initialised to
> (CROSS_COMPILE_COMPAT)gcc. This means that it is valid compiler (and
> it's an aarch64 compiler on my machine). The COMPATCC_IS_ARM_GCC
> silently disables the compat vDSO for this case rather than giving me a
> build error if we don't have such checks.
> 
> In the long run, I wouldn't mandate CROSS_COMPILE_COMPAT to always be
> set for the compat vDSO since with clang we could use the same compiler
> binary for both native and compat (with different flags). That's once we
> cleaned up the headers.

But we'll still need it even with clang so that the relevant triple can be
passed to the --target option. The top-level Makefile already does this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile#n544

so I think we should do the same thing for the compat vdso as well, which
would allow us to remove this complexity by requiring that
CROSS_COMPILE_COMPAT identifies the cross-compiler to use in exactly the
same way as CROSS_COMPILE does.

Am I missing something here?

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ