* Van De Ven, Arjan <arjan.van.de....@intel.com> wrote:
> > > IOW, is there some work on tooling/analysis/similar? Not asking for
> > > near-term, but more of a "big picture" question..
>
> short term there was some extremely rudimentary static analysis done. clearly
> that has extreme limitations both in insane rate of false positives, and
> missing
> cases.
What was the output roughly, how many suspect places that need
array_idx_nospec()
handling: a few, a few dozen, a few hundred or a few thousand?
I'm guessing 'static tool emitted hundreds of sites with many false positives
included, but the real sites are probably a few dozen' - but that's really just
a
very, very wild guess.
Our whole mindset and approach with these generic APIs obviously very much
depends
on the order of magnitude:
- For array users up to a few dozen per 20 MLOC code base accumulated over 20
years, and with no more than ~1 new site per kernel release we can probably
do what we do for buffer overflows: static analyze and fix via
array_idx_nospec().
- If it's more than a few dozen then intuitively I'd also be very much in favor
of
compiler help: for example trickle down __user annotations that Sparse uses
some
more and let the compiler sanitize indices or warn about them - without
hurting
performance of in-kernel array handling.
- If it's "hundreds" then probably both the correctness and the maintenance
aspects won't scale well to a 20+ MLOC kernel code base - in that case we
_have_
to catch the out of range values at a much earlier stage, at the system call
and
other system ABI level, and probably need to do it via a self-maintaining
approach such as annotations/types that also warns about 'unsanitized' uses.
But
filtering earlier has its own problems as well: mostly the layering
violations
(high level interfaces often don't know the safe array index range) can
create
worse bugs and more fragility than what is being fixed ...
- If it's "thousands" then it _clearly_ won't scale and we probably need
compiler
help: i.e. a compiler that tracks ranges and automatically sanitizes indices.
This will have some performance effect, but should result in almost immediate
correctness.
Also, IMHO any tooling should very much be open source: this isn't the kind of
bug
that can be identified via code review, so there's no fall-back detection
method
like we have for buffer overflows.
Anyway, the approach taken very much depends on the order of magnitude of such
affected array users we are targeting ...
Thanks,
Ingo
