[prev in list] [next in list] [prev in thread] [next in thread]
List: kernel-hardening
Subject: Re: [patch 8/8] rslib: Allocate decoder buffers to avoid VLAs
From: Kees Cook <keescook () chromium ! org>
Date: 2018-03-28 21:14:25
Message-ID: CAGXu5j+UUsR8=G93UHktjUSX3N8LsRvARNDRmNTiQGLzAAm=yw () mail ! gmail ! com
[Download RAW message or body]
On Wed, Mar 28, 2018 at 1:51 PM, Thomas Gleixner <tglx@linutronix.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@linutronix.de>
Regardless:
Acked-by: Kees Cook <keescook@chromium.org>
Thanks for doing this!
-Kees
--
Kees Cook
Pixel Security
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic