linux-kernel - Re: [PATCH] MIPS: malta: Set load address for 32bit kernel correctly

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.2004051738000.4156324@eddie.linux-mips.org>
Date:   Sun, 5 Apr 2020 17:47:29 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>
cc:     linux-mips@...r.kernel.org, Fangrui Song <maskray@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: malta: Set load address for 32bit kernel
 correctly

On Sun, 5 Apr 2020, Jiaxun Yang wrote:

> LLD failed to link vmlinux with 64bit load address for 32bit ELF
> while bfd will strip 64bit address into 32bit silently.
> To fix LLD build, we should supply a 32bit load address for 32bit
> kernel.
[...]
> diff --git a/arch/mips/mti-malta/Platform b/arch/mips/mti-malta/Platform
> index 2cc72c9b38e3..f9b49cba1764 100644
> --- a/arch/mips/mti-malta/Platform
> +++ b/arch/mips/mti-malta/Platform
> @@ -6,6 +6,10 @@ cflags-$(CONFIG_MIPS_MALTA)	+= -I$(srctree)/arch/mips/include/asm/mach-malta
>  ifdef CONFIG_KVM_GUEST
>      load-$(CONFIG_MIPS_MALTA)	+= 0x0000000040100000
>  else
> +ifdef CONFIG_64BIT
>      load-$(CONFIG_MIPS_MALTA)	+= 0xffffffff80100000
> +else
> +    load-$(CONFIG_MIPS_MALTA)	+= 0x80100000

 Given the description above I think it should be done uniformly and 
automatically across all platforms by trimming the address supplied with 
$(load-y) to low 8 digits in a single place, that is at the place where 
the variable is consumed.  This will reduce clutter across Makefile 
fragments, avoid inconsistencies and extra work to handle individual 
platforms as the problem is triggered over and over again, and limit the 
risk of mistakes.

 Some error checking might be doable for verifying that the 64-bit address 
truncated is a sign-extended 32-bit value, but that perhaps would be an 
overkill as certainly any 64-bit system that sets the load address to be 
outside the sign-extended 32-bit address range does not support a !64BIT 
configuration anyway.

  Maciej