Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 23 Apr 2020 13:42:52 +0800
From:   Jiaxun Yang <jiaxun.yang@flygoat.com>
To:     "Maciej W. Rozycki" <macro@linux-mips.org>
CC:     linux-mips@vger.kernel.org, clang-built-linux@googlegroups.com,
        Fangrui Song <maskray@google.com>,
        Kees Cook <keescook@chromium.org>,
        Nathan Chancellor <natechancellor@gmail.com>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Paul Burton <paulburton@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Jouni Hogander <jouni.hogander@unikie.com>,
        Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>,
        Borislav Petkov <bp@suse.de>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] MIPS: Truncate link address into 32bit for 32bit kernel
User-Agent: K-9 Mail for Android
Reply-to: jiaxun.yang@flygoat.com
In-Reply-To: <alpine.LFD.2.21.2004230036480.851719@eddie.linux-mips.org>
References: <20200413062651.3992652-1-jiaxun.yang@flygoat.com> <20200422143258.1250960-1-jiaxun.yang@flygoat.com> <alpine.LFD.2.21.2004230036480.851719@eddie.linux-mips.org>
Message-ID: <B307BFAC-9973-4444-B69A-40B054210E84@flygoat.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


=E4=BA=8E 2020=E5=B9=B44=E6=9C=8823=E6=97=A5 GMT+08:00 =E4=B8=8A=E5=8D=888=
:10:12, "Maciej W=2E Rozycki" <macro@linux-mips=2Eorg> =E5=86=99=E5=88=B0:
>On Wed, 22 Apr 2020, Jiaxun Yang wrote:
>
>> Reviewed-by: Maciej W=2E Rozycki <macro@linux-mips=2Eorg>
>
> Hmm, that was for an earlier version of the patch, and reviews obviously=
=20
>do not automatically carry over to subsequent versions, as it cannot be=
=20
>claimed that they are as good in the reviewer's eyes as the actual versio=
n=20
>reviewed was=2E
>
>> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
>> index e1c44aed8156=2E=2E68c0f22fefc0 100644
>> --- a/arch/mips/Makefile
>> +++ b/arch/mips/Makefile
>> @@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
>>    endif
>>  endif
>> =20
>> +# When linking a 32-bit executable the LLVM linker cannot cope with a
>> +# 32-bit load address that has been sign-extended to 64 bits=2E  Simpl=
y
>> +# remove the upper 32 bits then, as it is safe to do so with other
>> +# linkers=2E
>> +ifdef CONFIG_64BIT
>> +	load-ld			=3D $(load-y)
>> +else
>> +	load-ld			=3D $(subst 0xffffffff,0x,$(load-y))
>> +endif
>> +
>>  KBUILD_AFLAGS	+=3D $(cflags-y)
>>  KBUILD_CFLAGS	+=3D $(cflags-y)
>> -KBUILD_CPPFLAGS +=3D -DVMLINUX_LOAD_ADDRESS=3D$(load-y)
>> +KBUILD_CPPFLAGS +=3D -DVMLINUX_LOAD_ADDRESS=3D$(load-y) -DVMLINUX_LINK=
_ADDRESS=3D$(load-ld)
>>  KBUILD_CPPFLAGS +=3D -DDATAOFFSET=3D$(if $(dataoffset-y),$(dataoffset-=
y),0)
>> =20
>>  bootvars-y	=3D VMLINUX_LOAD_ADDRESS=3D$(load-y) \
>> +		  VMLINUX_LINK_ADDRESS=3D$(load-ld) \
>>  		  VMLINUX_ENTRY_ADDRESS=3D$(entry-y) \
>>  		  PLATFORM=3D"$(platform-y)" \
>>  		  ITS_INPUTS=3D"$(its-y)"
>
> Hmm, to be honest I find the nomenclature confusing: VMLINUX_LOAD_ADDRES=
S=20
>and VMLINUX_LINK_ADDRESS sound like synonyms to me and also look very=20
>similar, so I expect people will be confused and scratch their heads in=
=20
>the future=2E  Due to the obscurity of the problem I think there is littl=
e=20
>room for manoeuvre here really, but how about using LINKER_LOAD_ADDRESS=
=20
>for the new variable?
>
> Alternatively, have you made any attempt to verify if actually replacing=
=20
>the setting for VMLINUX_LOAD_ADDRESS would be safe?  Glancing over its us=
e=20
>there do not appear to be many places=2E

Limited experiments showed it should be fine=2E=2E=2E

But MIPS kernel has some design I'm not really familiar with like SYM32 fo=
r
64-bit kernel and special address space design for Trap-and-emul KVM=2E

I'm not 100 sure it's safe so I didn't do so=2E

>
>  Maciej

--=20
Jiaxun Yang