linux-kernel - Re: [PATCH] ARM: fix randomized task

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]

Message-ID: <CAKv+Gu8=qubUV9q7LKEN6BCXro9UGa7=_9_f810-DSbzx4ysmw@mail.gmail.com>
Date:   Fri, 30 Jun 2017 17:34:18 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>,
        kernel-hardening@...ts.openwall.com,
        Will Deacon <will.deacon@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: fix randomized task_struct

On 30 June 2017 at 15:55, Russell King - ARM Linux
<linux@...linux.org.uk> wrote:
> On Fri, Jun 30, 2017 at 03:49:41PM +0000, Ard Biesheuvel wrote:
>>
>>
>> > On 30 Jun 2017, at 15:34, Arnd Bergmann <arnd@...db.de> wrote:
>> >
>> > With the new task struct randomization, we can run into a build
>> > failure for certain random seeds:
>> >
>> > arch/arm/kernel/entry-armv.S: Assembler messages:
>> > arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096)
>> >
>> > Only two constants in asm-offset.h are affected, and I'm changing
>> > both of them here to work correctly in all configurations.
>> >
>> > One more macro has the problem, but is currently unused, so this
>> > removes it instead of adding complexity.
>> >
>> > Suggested-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> > Fixes: c33d8b12fbbd ("task_struct: Allow randomized layout")
>> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> > ---
>> > arch/arm/kernel/entry-armv.S |  5 ++++-
>> > arch/arm/mm/proc-macros.S    | 10 ++++------
>> > 2 files changed, 8 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> > index 9f157e7c51e7..db6d22b23bd8 100644
>> > --- a/arch/arm/kernel/entry-armv.S
>> > +++ b/arch/arm/kernel/entry-armv.S
>> > @@ -797,7 +797,10 @@ ENTRY(__switch_to)
>> > #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
>> >    ldr    r7, [r2, #TI_TASK]
>> >    ldr    r8, =__stack_chk_guard
>> > -    ldr    r7, [r7, #TSK_STACK_CANARY]
>> > +    .if (TSK_STACK_CANARY > PAGE_MASK)
>>
>> Shouldn't this be ~PAGE_MASK?
>>
>> I think
>>
>> .if (TSK_STACK_CANARY & PAGE_MASK) != 0
>>
>> is better and clearer as well
>
> It's not really that much clearer - what has any of this got to do with
> the size of a page?  Just because a definition appears to be numerically
> the same, it doesn't mean it should be used!
>
> The LDR instruction takes a maximum of a 12-bit constant.  This 12-bit
> constant has nothing to do with the page size; it's been that way since
> the early ARMs that knew nothing about page tables.
>
> Please instead create a LDR_IMM12_MASK or similar definition for this.
>

Yes, good point.