On Sun, Dec 09, 2018 at 03:29:16PM -0700, Tycho Andersen wrote: > On Sun, Dec 09, 2018 at 11:25:57PM +0100, Luc Van Oostenryck wrote: > > On Sun, Dec 09, 2018 at 11:17:50PM +0100, Luc Van Oostenryck wrote: > > > On Sun, Dec 09, 2018 at 02:53:09PM -0700, Tycho Andersen wrote: > > > > > * add a new annotation to force sparse to check the byte count > > > > > (I'm thinking about __range__/OP_RANGE or something similar). > > > > > > > > Yes, I was playing around with inventing some check like this without > > > > the need for an annotation. It's not clear to me if it's going to work > > > > or not yet, though :). Top two patches here are what I was playing > > > > with: > > > > > > > > https://github.com/tych0/sparse/commits/check-as-infoleaks > > > > > > > > > Then src is not a PSEUDO_SYM (it should be a PSEUDO_REG equal to > > > a PSEUDO_SYM plus fred's offset). > > > > There is the same problem for the first patch/check_no_kernel_pointers(). > > But the case PSEUDO_SYM + offset should be easy to handle. > > Right thanks. Unfortunately in the two cases I know about where this > could catch something: > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/block/floppy.c?h=v4.20-rc2&id=65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e > [2]: https://lkml.org/lkml/2018/11/3/142 > > there is some void* casting polluting the arguments, so I don't think > it will work. Do you have any tricks for things like this? I think that for these sort of checks (involving the type), it's too late to do it in check_call_instruction(). Basically sparse works like: 1) Parsing: parse the input file and create the Abstract Syntax Trees (mainly struct statement & struct expression) and return the list of all used symbols. 2) (type) Evaluation: Give a type to all symbols and expressions. This include all the typechecking. That's what sparse_initialize() and sparse() are used for. 3) Expansion (aka expansion): evaluate all the constant expressions). 4) Linearization: translate the statements into pseudo-instructions contained in basic blocks contained in a struct entrypoint. Also simplify/optimize these instructions. This simplification 'destroy' part of the information contained in the functions (for example, type information after a null cast is optimized away). This is what's returned by linearize_symbol(). 5) sparse do a few checks on the pseudo-instructions. For the sort of checks you're doing, it would be better to stop at Evaluation + Expansion, because you still have all information about objects and their type. Best regards, -- Luc
