Re: I would like to contribute to smatch

[Dan Carpenter <dan.carpenter@oracle.com>]

Hi Joel,

Smatch has two checks for Spectre v1 issues:

ipc/sem.c:445 sem_unlock() warn: potential spectre issue 'sma->sems' [r]

	copy_from_user(var, src, size);
	if (var >= ARRAY_SIZE())
		return -EINVAL;
	foo = array[bar];

These warning are for when we read from an array without using
array_index_nospec() or a different method of turning off speculation.
One of the issues with this warning is that most are not exploitable.

The second warning is for Spectre second halves:

block/genhd.c:117 __disk_get_part() warn: possible spectre second half.  '__u.__val'

	/* First half */
	copy_from_user(var, src, size);
	if (var >= ARRAY_SIZE())
		return -EINVAL;
	foo = array[bar];

	/* The second half is when we use "foo" */
	if (foo) {

I'm looking through the warnings now and they seem pretty low
quality...  :(  Part of it is that the CPU can only speculate maybe 200
instructions ahead so if the bounds checking is a long way from the
first or second half then it's not exploitable.  I think what's
is that it's restarting the clock at the start of the function?

I could just check to see if we have compared the index with something
in the function.  That's stored in smatch_comparison.c.  Or I could pass
the counter and store that in the DB.  I would be counting C statements
and not machine instructions, but they are obviously correlated.

What would really help me is if someone looked through the results and
pointed out what's false positives.

Btw, the smatch_data/db/smdb.py script is really essential to
understanding any of the spectre warnings.  It's looking at USER_DATA
which comes from copy_from_user() etc.

Also it's essential to build the DB.  The Smatch program to do that is:
~/smatch/smatch_scripts/build_kernel_data.sh
It's straightforward, but it takes 5 hours to complete.

regards,
dan carpenter