linux-kernel - Re: [RFC PATCH 0/8] arm64: move thread

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]

Message-ID: <20160921103147.GD18176@leverpostej>
Date:   Wed, 21 Sep 2016 11:31:47 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Laura Abbott <labbott@...hat.com>
Cc:     linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
        ard.biesheuvel@...aro.org, catalin.marinas@....com,
        james.morse@....com, keescook@...omium.org,
        linux-kernel@...r.kernel.org, lorenzo.pieralisi@....com,
        luto@...nel.org, suzuki.poulose@....com,
        takahiro.akashi@...aro.org, will.deacon@....com,
        kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH 0/8] arm64: move thread_info off of the task stack

On Tue, Sep 20, 2016 at 06:26:54PM -0700, Laura Abbott wrote:
> On 09/15/2016 06:49 AM, Mark Rutland wrote:
> >Building atop of Andy's work on x86 and generic code, these patches move
> >arm64's thread_info off of the stack and into task_struct. This protects
> >thread_info from corruption in the face of stack overflow, and serves as
> >a step towards fully robust stack overflow handling will be addressed by
> >subsequent patches.
> >
> >In contrast to x86, we can't place some critical data such as
> >preempt_count in percpu variables, and we must store these in some
> >per-task location. This, compounded with the way headers are organised
> >conspires to require us to still define our own thread_info. I
> >understand that the longer term plan is to kill off thread_info
> >entirely, hence I'm sending this as an RFC so we can figure out if/how
> >we can achieve that.
> >
> >These patches are based on Andy's x86/vmap_stack branch [1,2], and I've
> >pushed a copy to me arm64/ti-stack-split branch [3,4]. The result of
> >these patches boots happily on platforms within reach of my desk, but
> >has not seen much stressing so far.
> 
> FWIW, I used your ti-stack-split branch while running some kernel builds
> and it seems to work well enough. You can take that as a Tested-by or I
> can re-test with a non-RFC version.

Thanks for testing, and many thanks for the offer!

Based on Andy's feedback some core bits are changing, and I'm hoping to
have a non-RFC version out soon once I've fixed up the remaining
fallout. I'll make sure you're Cc'd!

Thanks,
Mark.