From: Thomas Gleixner <tglx@linutronix.de>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
Segher Boessenkool <segher@kernel.crashing.org>,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots
Date: Fri, 9 Mar 2018 16:49:28 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.1803091610120.1364@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180309144613.GA48965@beast>
On Fri, 9 Mar 2018, Kees Cook wrote:
> Avoid VLAs[1] by always allocating the upper bound of stack space
> needed. The existing users of rslib appear to max out at 32 roots,
> so use that as the upper bound.
I think 32 is plenty. Do we have actually a user with 32?
> Alternative: make init_rs() a true caller-instance and pre-allocate
> the workspaces. Will this need locking or are the callers already
> single-threaded in their use of librs?
init_rs() is an init function which needs to be invoked _before_ the
decoder/encoder can be used.
The way it works today that it can share the rs_control between users to
avoid duplicating the polynom arrays and the setup of them.
So we might change how rs_control works and allocate rs_control for each
invocation of init_rs(). That means we need two data structures:
Rename rs_control to rs_poly and just use that internaly for sharing the
polynom arrays.
rs_control then becomes:
struct rs_control {
struct rs_poly *poly;
uint16_t lamda[MAX_ROOTS + 1];
....
uint16_t loc[MAX_ROOTS];
};
But as you said that requires serialization or separation at the usage
sites.
drivers/mtd/nand/* would either need a mutex or allocate one rs_control per
instance. Simple enough to do.
drivers/md/dm-verity-fec.c looks like it's allocating a dm control struct
for each worker thread, so that should just require allocating one
rs_control per worker then.
pstore only has an issue in case of OOPS. A simple solution would be to
allocate two rs_control structs, one for regular usage and one for the OOPS
case. Not sure if that covers all possible problems, so that needs more
thoughts.
Thanks,
tglx
next prev parent reply other threads:[~2018-03-09 15:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 14:46 [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots Kees Cook
2018-03-09 15:49 ` Thomas Gleixner [this message]
2018-03-09 20:57 ` Kees Cook
2018-03-09 22:57 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1803091610120.1364@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).