linux-kernel - Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 28 Jul 2017 19:58:18 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
cc:     Arnd Bergmann <arnd@...db.de>,
        linux-arm-kernel@...ts.infradead.org,
        Peter Zijlstra <peterz@...radead.org>,
        Matt Hart <matthew.hart@...aro.org>,
        Stefan Agner <stefan@...er.ch>,
        Chris Brandt <chris.brandt@...esas.com>,
        Russell King <rmk+kernel@....linux.org.uk>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

On Sat, 29 Jul 2017, Ard Biesheuvel wrote:

> 
> 
> > On 28 Jul 2017, at 16:27, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> > 
> >> On Fri, 28 Jul 2017, Arnd Bergmann wrote:
> >> 
> >> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB
> >> xipImage size after the __bug_table change.
> >> 
> >> I tried out a few things and found that moving the bug table
> >> into the .data section avoids this problem. However, the
> >> linker script magic is beyond my capabilities here, so this
> >> is almost certainly not correct.
> > 
> > Well, before your patch the BUG_TABLE location as well as its runtime 
> > functionality were completely wrong and broken.
> > 
> >> I've added a few people to Cc that understand this better
> >> than I do, hopefully someone can turn my bogus patch into
> >> a proper one.
> > 
> > Your patch isn't as bad as you make it, but maybe the following will 
> > avoid open recoding BUG_TABLE locally:
> > 
> > diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> > index 8265b11621..21b4b29c2f 100644
> > --- a/arch/arm/kernel/vmlinux-xip.lds.S
> > +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> > @@ -237,13 +237,13 @@ SECTIONS
> >         */
> >        DATA_DATA
> >        CONSTRUCTORS
> > -
> > -        _edata = .;
> >    }
> > -    _edata_loc = __data_loc + SIZEOF(.data);
> > 
> >    BUG_TABLE
> > 
> 
> The .data section is deliberately emitted with LMA != VMA so that the 
> code refers to the correct offset in RAM while the initial contents 
> are in ROM and are copied into RAM by the startup code.

You're right of course.  And I have no excuse as the relevant part of 
the startup code is actually mine.

> This applies to the bug table as well (now that it needs to be 
> writable) so the only correct way to do this is to move it into .data 
> like Arnd's patch does.

I got distracted by trying to reuse the macro as is and therefore I 
didn't fix anything.

> I guess we could split the macro so we can emit bug table into an 
> existing section, but in itself, the code is correct, and i don't see 
> a better way of doing it.

Agreed.


Nicolas