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]
Date:   Sat, 29 Jul 2017 00:04:31 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Nicolas Pitre <nicolas.pitre@...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 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.

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 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.

> +    _edata = .;
> +    _edata_loc = __data_loc + SIZEOF(.data);
> +
> #ifdef CONFIG_HAVE_TCM
>         /*
>     * We align everything to a page boundary so we can
> 
> 
> Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ