3 ms·
The VLA security problems are a bit of a myth. In the kernel it may be some problem, but with stack clash protection (which one should activate anyway) there is
by uecker 3y ago
The VLA security problems are a bit of a myth. In the kernel it may be some problem, but with stack clash protection (which one should activate anyway) there isn't really a inherent security issue anymore. The code quality improvements of using VLAs usually make it worth using them IMHO.
- pjmlp 3y agoA myth that was worth every penny fixing it, as per Google.
- uecker 3y agoDo you have link? BTW: I was tangentially involved in this effort...
- pjmlp 3y agoIt was on my original comment. Also there were a couple of talks from Linux Plumbers Conference given by Kees Cook, if I recall correctly.
- uecker 3y agoI now regret helping with this effort, since people use it as arguments against using VLAs in general, although in my opinion this is clearly the wrong conclusion outside of the kernel. VLAs are basically always superior to the next best alternative: They are safer than alloca() (and standard's compliant), they are faster than heap allocation (and similar safe), and use less stack and allow better bounds checking than a worst-case fixed-size arrays on the stack (but are slower).