linux-kernel - Re: [patch 8/8] rslib: Allocate decoder buffers to avoid VLAs

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: <CAGXu5j+UUsR8=G93UHktjUSX3N8LsRvARNDRmNTiQGLzAAm=yw@mail.gmail.com>
Date:   Wed, 28 Mar 2018 14:14:25 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Alasdair Kergon <agk@...hat.com>,
        Mike Snitzer <snitzer@...hat.com>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>
Subject: Re: [patch 8/8] rslib: Allocate decoder buffers to avoid VLAs

On Wed, Mar 28, 2018 at 1:51 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> To get rid of the variable length arrays on stack in the RS decoder it's
> necessary to allocate the decoder buffers per control structure instance.
>
> All usage sites have been checked for potential parallel decoder usage and
> fixed where necessary. Kees confirmed that the pstore decoding is strictly
> single threaded so there should be no surprises.

For posterity: pstore ecc decode happens during probe and during read.
The read (pstore_get_backend_records()) has an explicit read_mutex.

I was pondering, though, since we have a common control structure now,
maybe we should just add a spinlock too to avoid future surprises?

> Allocate them in the rs control structure sized depending on the number of
> roots for the chosen codec and adapt the decoder code to make use of them.
>
> Document the fact that decode operations based on a particular rs control
> instance cannot run in parallel and the caller has to ensure that as it's
> not possible to provide a proper locking construct which fits all use
> cases.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

Regardless:

Acked-by: Kees Cook <keescook@...omium.org>

Thanks for doing this!

-Kees

-- 
Kees Cook
Pixel Security