On Sat, 7 Dec 2024 at 11:19, Martin Uecker <muecker@xxxxxxx> wrote:
>
> But that all seem solvable issues on the compiler side.
You know, there was a whole *architecture* that was designed and
predicated on "it's all solvable on the compiler side".
That architecture was pure and utter *shit*.
Because no, it's not solvable on the compiler side.
Getting things like value range analysis right on the compiler side is
fundamentally hard.
It's hard to the point where either you only get it for the simple
cases - yes, I can show you a ton of real code where it's trivial - or
you need to have explicit markings in the source code to help the
compiler, and then you end up having to have the compiler (or some
other tool) validate those with asserts or whatever.
And random asserts ARE NOT ACCEPTABLE in the kernel outside of pure
debug builds.
They may be acceptable in most other situations, but in a kernel you
can't just say "we stop now because it turns out the analysis was
broken and the manual notes could be fooled by an attacker".
Now, would we want to have proper value *static* range analysis in the
kernel for other reasons? Oh yes. It would often be very nice to have
the ability to state "this value is trusted and is in this range", and
have it percolate all the way down, both for optimization purposes but
also for various sanity check purposes.
But it's simply not sanely available in the generic case.
> a) this is not guaranteed in a specific situation (-Wvla-larher-than)
We'd either get horrendous numbers of false positives that we then
have to manually add special code for, or
> b) transform the array automatically to fixed size array
> of size X *or* something smaller when it can show this.
we'd just do this by hand *once* and for all, and say "VLA's didn't work out".
So yeah. We did (b) by hand.
We used to have VLA's in the kernel. It was a disaster. We got rid of
them, because the (big) pain wasn't worth the (few) places it was
actually useful.
So we have been VLA-free for the last five years, and it's been good.
Simplify.
Linus
