Re: alloca() in kernel code
On 2019-10-13 01:18, Joerg Sonnenberger wrote: On Sun, Oct 13, 2019 at 12:46:24AM +0200, Johnny Billquist wrote: 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. I don't agree. No matter if we can tell what dynamic size means. We cannot allow allocation of arbitrary sized data on the stack. We know there is an upper limit before the system will crash. So either we immediately go for that limit (if we think we need that much), or we try to play dynamically, with a limiter at that limit. Plying it "dynamically" with a limiter then does not really gain us anything, so why do it? That was my point. Dynamic data in a kernel is problematic. Always. You always will have limitations on it, which are more restrictive than anything people write in user land. alloca() don't change that. If a fixed memory chunk isn't good enough, then alloca() will not really be any better, since it can't give you more anyway. It just does it (slightly) differently. If we need more memory than can be allocated on the stack, then you need to come up with other solutions. Just replacing a static size allocation with a call to alloca() don't solve any problem. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: alloca() in kernel code
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 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
Re: alloca() in kernel code
jo...@bec.de (Joerg Sonnenberger) writes: >> 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. More so than dynamic stack expansion. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: alloca() in kernel code
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 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. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: alloca() in kernel code
On Sat, Oct 12, 2019 at 02:01:16AM +0200, Emmanuel Dreyfus wrote: > I recently encountered a situation where I had to deal with variable > length structure at a time where kernel dynamic allocator was not > initialized. You can borrow pages directly if the data is potentially larger. Joerg
Re: alloca() in kernel code
On Sat, Oct 12, 2019 at 08:13:25PM +0200, Johnny Billquist wrote: > On 2019-10-12 19:01, Emmanuel Dreyfus wrote: > > Mouse 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. Joerg
Re: alloca() in kernel code
On 2019-10-12 19:01, Emmanuel Dreyfus wrote: Mouse 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()? It's not that it uses the stack, per se. That is obviously not the problem. The problem is that it can allocate arbitrary large amounts of data. And it is not, as Mouse suggested, a case of optimizing memory use. If we get into a function, any memory allocated by alloca() only have the lifetime of the executing function. But allowing arbitrary large chunks of data be allocated here is bad, since it can cause crashes is many silly ways. But any local variable in the function have the same property about lifetime, and have the same property about optimizing memory use, since when that function is not active, there is no memory used. And if we then know of an upper limit to what we would allow to be allocated through alloca(), why don't we just have a function local variable of that size already from the start. You are not going to use more memory than the worst case acceptable anyhow, which any called function still have to be able to run with (meaning how much stack is left). So what is the gain of using alloca()? You might be using less stack on a good day, but we already know the stack can handle the worst case anyhow, and this is temporary stuff, so there is honestly close to no gain from alloca() (you could possibly argue more locality benefits for values, such as hitting the same cache lines if the alloca() would be grabbing very little memory, but if you are trying to optimize for that detail, then you're pretty lost, since this varies a lot per CPU model and variant that you cannot do this is a sane way unless you are building very CPU specific code with a ton of constraints. What do we loose by using alloca()? In the best case nothing. In the worse case, you have created new vulnerabilities. So, again, why would you ever use alloca()? It's only a potential bad idea, with no real gains here. We cannot allow arbitrary size allocations anyhow, and for the limited size allocations, we must be sure we always work in the worse case, so why not do that from the start, and have a (more) sane situation. alloca() is just bad here. (And potentially bad in general.) And, sadly, C 11 also added a hidden alloca() into the base language itself, making life more miserable in general. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: alloca() in kernel code
Mouse 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. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: alloca() in kernel code
>> [...alloca() in kernel code...] > The kernel stack is rather small, we should not start allocating > variable-sized stuff on it. You say that as though the part after the comma follows from the part before it. If so, I don't understand why. The alternative seems to me to be to allocate a statically-sized buffer that's the maximum that could be needed - and, indeed, you remarked below (in text I've cut) that that's what you've done in such cases. But, surely, if you're short of stack, it's better to allocate only what you need, so the sum of the allocations is as small as possible, rather than to allocate maximum-sized buffers, whose total size will be as big as possible? I'm presumably missing something here, but what? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
