Retrieving status of local variables

Retrieving status of local variables

[Norbert Manthey]

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.

I wondered whether I simply miss something.

Best,
Norbert





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: Retrieving status of local variables

[Dan Carpenter]

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

Re: Retrieving status of local variables

[Dan Carpenter]

On Wed, May 12, 2021 at 08:13:59PM +0300, Dan Carpenter wrote:
> 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]"

I don't know why I put a [c] here.  That would not be capped, because
99 is a known limit.  Capped is only for when it's capped to an unknown
limit.
> 
> 	if (foo < x)
> 		<-- foo is "s32min-s32max[c]"

regards,
dan carpenter

Re: Retrieving status of local variables

[Norbert Manthey]

On 5/12/21 8:41 PM, Dan Carpenter wrote:
> On Wed, May 12, 2021 at 08:13:59PM +0300, Dan Carpenter wrote:
>> 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

Thanks for hinting at this. I will have a closer look whether I can use
the existing information, or whether I need to add a little more color
to it.

Best,
Norbert




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879