linux-kernel - Re: [PATCH v2] MIPS: Allow compressed images to be loaded at any address

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] [day] [month] [year] [list]

Date:   Mon, 12 Mar 2018 19:02:23 +0100
From:   Alban <albeu@...e.fr>
To:     James Hogan <james.hogan@...tec.com>
Cc:     Alban <albeu@...e.fr>, <linux-mips@...ux-mips.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Jonas Gorski <jogo@...nwrt.org>,
        <linux-kernel@...r.kernel.org>,
        Matt Redfearn <Matt.Redfearn@...tec.com>
Subject: Re: [PATCH v2] MIPS: Allow compressed images to be loaded at any
 address

On Mon, 13 Feb 2017 22:19:45 +0000
James Hogan <james.hogan@...tec.com> wrote:

> Hi Alban,
> 
> On Mon, Feb 13, 2017 at 09:38:08PM +0100, Alban wrote:
> > From: Alban Bedel <albeu@...e.fr>
> > 
> > Compressed images (vmlinuz.bin) have to be loaded at a specific
> > address that differ from the address normaly used for vmlinux.bin.
> > This is because the decompressor just write its output at the address
> > vmlinux.bin should be loaded at, and it shouldn't overwrite itself.
> > This limitation mean that the bootloader must be configured differently
> > when loading a vmlinux.bin or a vmlinuz.bin image, this is annoying
> > and a source of error.
> > 
> > To workaround this we extend the compressed loader to cope with being
> > loaded at (nearly) any address. During the early init a jump is used
> > to compute the offset between the current address and the linked
> > address, if they differ the whole image is first copied to the linked
> > address before proceeding.
> > 
> > Some load address won't work, for example if there is an overlap with
> > the range where vmlinuz.bin should be loaded. However for the typical
> > case of using the vmlinux.bin address that won't be the case.
> > 
> > Signed-off-by: Alban Bedel <albeu@...e.fr>
> > Suggested-by: Jonas Gorski <jonas.gorski@...il.com>
> > ---
> > Changelog:
> > v2: * Rework the code as suggested by Jonas Gorski to autodetect the
> >       load address and remove the need for a Kconfig option.
> > ---
> >  arch/mips/boot/compressed/head.S | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
> > index 409cb48..3c25a96 100644
> > --- a/arch/mips/boot/compressed/head.S
> > +++ b/arch/mips/boot/compressed/head.S
> > @@ -25,6 +25,29 @@ start:
> >  	move	s2, a2
> >  	move	s3, a3
> >  
> > +	/* Get the offset between the current address and linked address */
> > +	PTR_LA	t0, reloc_label
> > +	bal	reloc_label
> > +	 nop
> > +reloc_label:
> > +	subu	t0, ra, t0
> > +
> > +	/* If there is no offset no reloc is needed */
> > +	beqz	t0, clear_bss
> > +	 nop
> > +
> > +	/* Move the text, data section and DTB to the correct address */
> > +	PTR_LA	a0, .text
> > +	addu	a1, t0, a0
> > +	PTR_LA	a2, _edata
> > +copy_vmlinuz:
> > +	lw	a3, 0(a1)
> > +	sw	a3, 0(a0)
> > +	addiu	a0, a0, 4
> > +	bne	a2, a0, copy_vmlinuz
> > +	 addiu	a1, a1, 4  
> 
> Does this need to sync the icache and resolve the instruction hazard
> before jumping into the newly written code?
>
> E.g. on mips32/64 r2 and later you could I think "synci" at SYNCI_Step
> intervals (as determined by RDHWR instruction), followed by a "sync" and
> then using "jr.hb" instead of "jr" to clear the instruction hazard while
> jumping to the newly written code.
> 
> That is roughly what arch/mips/kernel/relocate.c and
> arch/mips/kernel/head.S do, but as mentioned that assumes MIPS32/64 r2+,
> and at least 2 platforms selecting SYS_SUPPORTS_ZBOOT* also select
> CPU_HAS_CPU_MIPS32_R1.

This was a long time ago but I still like to finish this. However I'm
not very really versed into this kind of very low level subjects, so
I would appreciate if somebody could tell me if the cache sync is needed
here or not. All I can says is that it currently work on ATH79 which is
a mips32 r2, but that doesn't mean it is correct.

Also note that no such cache sync is done on the decompressed kernel,
wouldn't that also be needed?

Alban

Content of type "application/pgp-signature" skipped