All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Norbert Manthey <nmanthey@amazon.de>
Cc: smatch@vger.kernel.org
Subject: Re: Retrieving status of local variables
Date: Wed, 12 May 2021 20:13:59 +0300	[thread overview]
Message-ID: <20210512171358.GY1955@kadam> (raw)
In-Reply-To: <c9490a36-2d71-7181-762b-03295b9e6956@amazon.de>

On Wed, May 12, 2021 at 05:15:06PM +0200, Norbert Manthey wrote:
> Dear all,
> 
> I would like to retrieve the information whether variables inside source
> files can be influenced from user land, e.g. to identify variables that
> store arguments to syscalls. Is there already a tool that offers this
> feature?
> 
> I understand that the 'smatch_data/db/smdb.py $func' tool can be used to
> trace calls to a function $func. Furthermore, 'smatch_data/db/smdb.py
> trace_param $func' allows to trace how function parameters are traced.
> However, both commands do not present the information I am looking for.
> I also did not find such labels in the tables of the created data base file.

Yes.  This is information is recorded in the DB.

$ smdb esas2r_read_vda | grep USER
drivers/scsi/esas2r/esas2r_ioctl.c | esas2r_ioctl_handler |      esas2r_read_vda |          USER_DATA |  3 |           count | s32min-s32max

The s32min-s32max is the range the user can set it to.  Smatch tracks
tagged pointers in ARM but I didn't write that code and don't remember
the details.  If the data is capped against an unknown value then there
would be a [c] "s32min-s32max[c]"

	if (foo < 100)
		<-- foo is "s32min-99[c]"

	if (foo < x)
		<-- foo is "s32min-s32max[c]"

There is also USER_PTR which records that an array holds user controlled
data.  There are a few different sources of user controlled information:
syscalls, kstrtoul(), sscanf(), copy_from_user(), kvm_register_read()
and skb->data.  I thought kmap() was in there, but I can't see it now.
memdup_user() uses copy_from_user() so it doesn't need to be hardcoded
in.

The code for this is in smatch_kernel_user_data.c and
smatch_points_to_user_data.c

You'll want to rebuild the cross function DB probably 5-7 times to build
out the call tree.

Let me know if you find any bugs in this because tracking user
controlled data is very important for me.  Subtraction is complicated to
handle properly so a lot of times at the end of subtraction Smatch will
just mark it as unknown but user controlled data.

regards,
dan carpenter

  reply	other threads:[~2021-05-12 17:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 15:15 Retrieving status of local variables Norbert Manthey
2021-05-12 17:13 ` Dan Carpenter [this message]
2021-05-12 18:41   ` Dan Carpenter
2021-05-12 19:25     ` Norbert Manthey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210512171358.GY1955@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=nmanthey@amazon.de \
    --cc=smatch@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.