Re: alloca() in kernel code

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, Oct 13, 2019 at 12:46:24AM +0200, Johnny Billquist wrote:
> On 2019-10-12 20:47, Joerg Sonnenberger wrote:
> > On Sat, Oct 12, 2019 at 08:13:25PM +0200, Johnny Billquist wrote:
> > > On 2019-10-12 19:01, Emmanuel Dreyfus wrote:
> > > > Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> > > > 
> > > > > I'm presumably missing something here, but what?
> > > > 
> > > > I suspect Maxime's concern is about uncontrolled stack-based variable
> > > > buffer, which could be used to crash the kernel.
> > > > 
> > > > But in my case, the data is coming from the bootloader. I cannot think
> > > > about a scenario where it makes sense to defend against an attack from
> > > > the bootloader. The kernel already has absolute trust in the bootloader.
> > > 
> > > On this one, I agree with Maxime.
> > > 
> > > Even if it comes from the bootloader, why would you want to use alloca()?
> > 
> > Because as Emmanuel wrote initially, dynamic allocations might not be
> > possible yet.
> 
> But if you use alloca(), you will have to check what size you'd like to
> allocate, and not allocate more than some maximum amount, I would assume. Or
> do you really think that it is ok to just let it try no matter what amount
> is decided you want to allocate?
> 
> And if you figure out an upper limit, then you might as well just define an
> array of that size in the function, and be done with it.

All nice and good, but it doesn't help with the original problem. How to
deal with dynamically sized data when there is no dynamic allocator.
Without context, it is impossible to know if "dynamic size" means a
reasonable sized string, a list of memory segments etc. As such, it is
impossible to say if alloca (or just defining a fixed size array or
whatever) is reasonable or not.

Joerg