Am Freitag, dem 01.03.2024 um 13:43 +0000 schrieb David Laight: > From: Uecker, Martin > > Sent: 01 March 2024 13:22 > > > > My suggestion would also to limit explanation. Nobody should > > write such code and if you need to, you can find explanations > > all over the internet. > > > > Finally, I still think the motivation for this macro (removing > > VLAs) is misguided if security is the goal because VLAs provide > > precise bounds and larger worst-case fixed-size arrays do not. > > > > It would be better to use the compiler options that detect > > possibly use of VLAs of unbounded size and if there a problems > > with this, improve this on the compiler side. > > In kernel code (with limited stack) there has to be enough room > for the largest possible 'VLA' so you might as well allocate one. > > Allowing VLA also makes it pretty much impossible to do any > kind of static stack use analysis. If you limit VLAs to a certain maximum size, then you could use this for analysis and it would not be worse than using worst case fixed-size array on the stack. But you can also use the *precise* run-time bound of the VLA if your static analysis is smart enough. You can also use the precise run-time bound for run-time bounds checking. It is strictly more expressive to use VLAs (or dependent types in general) and therefor *good* for static analysis. > The fine IBT tags can be used identify valid indirect calls > which pretty much only leaves recursion stopping full static > stack analysis - and that could be banned except for a few > limited cases where 1 level could be permittd. > > is_constexpr() has other uses - there are places where > __builtin_constant_p() isn't strong enough. > Particularly if you need to use builtin_choose_expr() > or _Generic() to get select a type. > > For instance, if you can a constant value between 0 and MAXINT > it is safe to cast to/from unsigned in order change any > implicit integer promotion cast that may be grief some. glad to hear it is useful. Martin > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
