public inbox for smatch@vger.kernel.org
 help / color / mirror / Atom feed
* I would like to contribute to smatch
@ 2019-05-03 18:36 Joel Savitz
  2019-05-03 19:32 ` Dan Carpenter
  0 siblings, 1 reply; 2+ messages in thread
From: Joel Savitz @ 2019-05-03 18:36 UTC (permalink / raw)
  To: smatch, error27, dan.carpenter

Good afternoon,

I am interested in contributing to smatch, especially with regards to
spectre v1 vulnerability detection in the Linux kernel.

I looked through the repository and found a small amount of
information on the project and current development efforts, but most
of it was with regards to sparse.

Anyway, how can I get started?

Do you have any recommendations with regards to relevant resources?

Best,
Joel Savitz

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: I would like to contribute to smatch
  2019-05-03 18:36 I would like to contribute to smatch Joel Savitz
@ 2019-05-03 19:32 ` Dan Carpenter
  0 siblings, 0 replies; 2+ messages in thread
From: Dan Carpenter @ 2019-05-03 19:32 UTC (permalink / raw)
  To: Joel Savitz; +Cc: smatch, error27

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-05-03 19:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-03 18:36 I would like to contribute to smatch Joel Savitz
2019-05-03 19:32 ` Dan Carpenter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox