Smatch for Xen

Smatch for Xen

[Norbert Manthey]

Dear Dan,

I use my one-line-scan tool [1] to run smatch against non-kernel
projects. However, for Xen I still use -p=kernel, to have all the
analysis enabled. I did not write an evaluation routine to present the
defects or statistics for smatch in a nice way, but smatch can be
invoked. For the latest Xen, smatch (actually sparse) seems to struggle
with the attribute __pointer__ token, as that's not defined.

A typical invocation for smatch would look like the following:

export SMATCH_EXTRA_ARG="-p=kernel --file-output"
one-line-scan -o SMATCH --smatch --no-gotocc --no-analysis \
  -- make xen -j $(nproc) -B

I will look into using the debug info next, and see how taint
information is propagated.

Best,
Norbert

[1] https://github.com/awslabs/one-line-scan

On 07/30/2018 07:28 AM, Dan Carpenter wrote:
> It doesn't feel like anything in this email is secret.  It would be
> better to move it to the public smatch mailing list:
> smatch@vger.kernel.org
>
> On Wed, Jul 25, 2018 at 07:59:17AM +0200, Norbert Manthey wrote:
>> Dear Dan,
>>
>> I recently looked into smatch a little closer, and tried to get it
>> working on Xen - the goal is to get the spectre analysis done for Xen as
>> well. Some of the other kernel analysis might be nice to have there as
>> well. A first swipe produced some warnings that actually look
>> interesting, and a bunch of output that might be noise. I did not fully
>> investigate all of them yet.
>>
>
> I downloaded the xen git tree.  How did you enable the Smatch build?
>
>> I wonder what else it takes to get taint analysis producing useful
>> results. UI already added some labels to function parameters and  guest
>> controllable variables with "__user", similarly to kernel code. Is there
>> a way I can extract all the variables that have been flagged as tainted
>> by smatch? That would help me debugging a lot.
>>
>
> Smatch doesn't use __user labels at all.  It just looks for the actual
> copy_from_user() function and marks *dest as tainted.
> See check_user_data2.c for how that works.
>
> There are a bunch of ways to look at Smatch's internals.  The
> smatch_data/db/smdb.py script will show what information is passed to
> a function or what it returns.  Also you can include the "check_debug.h"
> file and add a call to __smatch_states("check_user_data2"); or
> __smatch_user_rl(variable);.  The __smatch_states() takes the name of
> the function in check_list.h and prints out any states.  The
> __smatch_user_rl() function prints out what the user can set like "0-9".
> Look through check_debug.h.
>
>
> regards,
> dan carpenter
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

[PATCH 0/3] add support for mode __pointer__ & __byte__

[Luc Van Oostenryck]

This series contains missing support for mode __pointer__ &
__byte__ as well as a small preliminary cleanup.

This series is available for testing & review in the repository at:
  git://github.com/lucvoo/sparse-dev.git mode-pointer

----------------------------------------------------------------
Luc Van Oostenryck (3):
  mode keywords don't need MOD_{CHAR,LONG,...}
  add support for mode __pointer__
  add support for mode __byte__

 parse.c | 44 +++++++++++++++++++++++++++++++-------------
 1 file changed, 31 insertions(+), 13 deletions(-)

-- 
2.18.0

[PATCH 1/3] mode keywords don't need MOD_{CHAR,LONG,...}

[Luc Van Oostenryck]

The keywords for modes (SI, DI, ...) don't need a length modifier
like MOD_CHAR or MOD_LONG as the corresponding type (and thus its
length) is given by the the '.to_mode' method.

Remove these modifiers from the keyword definitions, their presence
while unneeded is confusing.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 parse.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/parse.c b/parse.c
index 270ab7bfd..0cafb4e6c 100644
--- a/parse.c
+++ b/parse.c
@@ -538,18 +538,18 @@ static struct init_keyword {
 	{"__const__",	NS_KEYWORD,	MOD_PURE,	.op = &attr_mod_op },
 
 	{ "__mode__",	NS_KEYWORD,	.op = &mode_op },
-	{ "QI",		NS_KEYWORD,	MOD_CHAR,	.op = &mode_QI_op },
-	{ "__QI__",	NS_KEYWORD,	MOD_CHAR,	.op = &mode_QI_op },
-	{ "HI",		NS_KEYWORD,	MOD_SHORT,	.op = &mode_HI_op },
-	{ "__HI__",	NS_KEYWORD,	MOD_SHORT,	.op = &mode_HI_op },
-	{ "SI",		NS_KEYWORD,			.op = &mode_SI_op },
-	{ "__SI__",	NS_KEYWORD,			.op = &mode_SI_op },
-	{ "DI",		NS_KEYWORD,	MOD_LONGLONG,	.op = &mode_DI_op },
-	{ "__DI__",	NS_KEYWORD,	MOD_LONGLONG,	.op = &mode_DI_op },
-	{ "TI",		NS_KEYWORD,	MOD_LONGLONGLONG,	.op = &mode_TI_op },
-	{ "__TI__",	NS_KEYWORD,	MOD_LONGLONGLONG,	.op = &mode_TI_op },
-	{ "word",	NS_KEYWORD,	MOD_LONG,	.op = &mode_word_op },
-	{ "__word__",	NS_KEYWORD,	MOD_LONG,	.op = &mode_word_op },
+	{ "QI",		NS_KEYWORD,	.op = &mode_QI_op },
+	{ "__QI__",	NS_KEYWORD,	.op = &mode_QI_op },
+	{ "HI",		NS_KEYWORD,	.op = &mode_HI_op },
+	{ "__HI__",	NS_KEYWORD,	.op = &mode_HI_op },
+	{ "SI",		NS_KEYWORD,	.op = &mode_SI_op },
+	{ "__SI__",	NS_KEYWORD,	.op = &mode_SI_op },
+	{ "DI",		NS_KEYWORD,	.op = &mode_DI_op },
+	{ "__DI__",	NS_KEYWORD,	.op = &mode_DI_op },
+	{ "TI",		NS_KEYWORD,	.op = &mode_TI_op },
+	{ "__TI__",	NS_KEYWORD,	.op = &mode_TI_op },
+	{ "word",	NS_KEYWORD,	.op = &mode_word_op },
+	{ "__word__",	NS_KEYWORD,	.op = &mode_word_op },
 };
 
 
-- 
2.18.0

[PATCH 2/3] add support for mode __pointer__

[Luc Van Oostenryck]

sparse support GCC's modes like __SI__, __DI__, and __word__
but GCC also supports a mode __pointer__ which is used by Xen.

Add support for this missing __pointer__ mode.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 parse.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/parse.c b/parse.c
index 0cafb4e6c..845b2c167 100644
--- a/parse.c
+++ b/parse.c
@@ -91,7 +91,8 @@ static attr_t
 typedef struct symbol *to_mode_t(struct symbol *);
 
 static to_mode_t
-	to_QI_mode, to_HI_mode, to_SI_mode, to_DI_mode, to_TI_mode, to_word_mode;
+	to_QI_mode, to_HI_mode, to_SI_mode, to_DI_mode, to_TI_mode;
+static to_mode_t to_pointer_mode, to_word_mode;
 
 enum {
 	Set_T = 1,
@@ -410,6 +411,11 @@ static struct symbol_op mode_TI_op = {
 	.to_mode = to_TI_mode
 };
 
+static struct symbol_op mode_pointer_op = {
+	.type = KW_MODE,
+	.to_mode = to_pointer_mode
+};
+
 static struct symbol_op mode_word_op = {
 	.type = KW_MODE,
 	.to_mode = to_word_mode
@@ -548,6 +554,8 @@ static struct init_keyword {
 	{ "__DI__",	NS_KEYWORD,	.op = &mode_DI_op },
 	{ "TI",		NS_KEYWORD,	.op = &mode_TI_op },
 	{ "__TI__",	NS_KEYWORD,	.op = &mode_TI_op },
+	{ "pointer",	NS_KEYWORD,	.op = &mode_pointer_op },
+	{ "__pointer__",NS_KEYWORD,	.op = &mode_pointer_op },
 	{ "word",	NS_KEYWORD,	.op = &mode_word_op },
 	{ "__word__",	NS_KEYWORD,	.op = &mode_word_op },
 };
@@ -1105,6 +1113,14 @@ static struct symbol *to_TI_mode(struct symbol *ctype)
 						     : &slllong_ctype;
 }
 
+static struct symbol *to_pointer_mode(struct symbol *ctype)
+{
+	if (ctype->ctype.base_type != &int_type)
+		return NULL;
+	return ctype->ctype.modifiers & MOD_UNSIGNED ? uintptr_ctype
+						     :  intptr_ctype;
+}
+
 static struct symbol *to_word_mode(struct symbol *ctype)
 {
 	if (ctype->ctype.base_type != &int_type)
-- 
2.18.0

[PATCH 3/3] add support for mode __byte__

[Luc Van Oostenryck]

sparse support GCC's modes like __SI__, __DI__, as well as
__word__ & __pointer__ but GCC also supports a mode __byte__.

For completeness, add this mode as an alias for mode __QI__.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 parse.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/parse.c b/parse.c
index 845b2c167..950da3646 100644
--- a/parse.c
+++ b/parse.c
@@ -554,6 +554,8 @@ static struct init_keyword {
 	{ "__DI__",	NS_KEYWORD,	.op = &mode_DI_op },
 	{ "TI",		NS_KEYWORD,	.op = &mode_TI_op },
 	{ "__TI__",	NS_KEYWORD,	.op = &mode_TI_op },
+	{ "byte",	NS_KEYWORD,	.op = &mode_QI_op },
+	{ "__byte__",	NS_KEYWORD,	.op = &mode_QI_op },
 	{ "pointer",	NS_KEYWORD,	.op = &mode_pointer_op },
 	{ "__pointer__",NS_KEYWORD,	.op = &mode_pointer_op },
 	{ "word",	NS_KEYWORD,	.op = &mode_word_op },
-- 
2.18.0

Re: Smatch for Xen

[Dan Carpenter]

On Mon, Jul 30, 2018 at 02:40:08PM +0200, Norbert Manthey wrote:
> Dear Dan,
> 
> I use my one-line-scan tool [1] to run smatch against non-kernel
> projects. However, for Xen I still use -p=kernel, to have all the
> analysis enabled. I did not write an evaluation routine to present the
> defects or statistics for smatch in a nice way, but smatch can be
> invoked. For the latest Xen, smatch (actually sparse) seems to struggle
> with the attribute __pointer__ token, as that's not defined.
> 
> A typical invocation for smatch would look like the following:
> 
> export SMATCH_EXTRA_ARG="-p=kernel --file-output"
> one-line-scan -o SMATCH --smatch --no-gotocc --no-analysis \
>   -- make xen -j $(nproc) -B
> 
> I will look into using the debug info next, and see how taint
> information is propagated.
> 

I tried use one-line-scan but I didn't want to install it in my $PATH so
I couldn't figure out how to make it work...

Then I tried to export CC=~/path/to/smatch/cgcc and
HOSTCC=~/path/to/smatch/cgcc but it only builds:

boot/mkelf32.c
config/zconf.tab.c
efi/mkreloc.c
symbols.c
tools/kconfig/conf.c
tools/kconfig/zconf.tab.c

Which is useles...

regards,
dan carpenter

Re: Smatch for Xen

[Dan Carpenter]

On Mon, Aug 06, 2018 at 01:31:32PM +0300, Dan Carpenter wrote:
> On Mon, Jul 30, 2018 at 02:40:08PM +0200, Norbert Manthey wrote:
> > Dear Dan,
> > 
> > I use my one-line-scan tool [1] to run smatch against non-kernel
> > projects. However, for Xen I still use -p=kernel, to have all the
> > analysis enabled. I did not write an evaluation routine to present the
> > defects or statistics for smatch in a nice way, but smatch can be
> > invoked. For the latest Xen, smatch (actually sparse) seems to struggle
> > with the attribute __pointer__ token, as that's not defined.
> > 
> > A typical invocation for smatch would look like the following:
> > 
> > export SMATCH_EXTRA_ARG="-p=kernel --file-output"
> > one-line-scan -o SMATCH --smatch --no-gotocc --no-analysis \
> >   -- make xen -j $(nproc) -B
> > 
> > I will look into using the debug info next, and see how taint
> > information is propagated.
> > 
> 
> I tried use one-line-scan but I didn't want to install it in my $PATH so
> I couldn't figure out how to make it work...
> 

I got one-line-scan to work I think but it still only built those three
files.  :(

regards,
dan carpenter

Re: Smatch for Xen

[Dan Carpenter]

On Mon, Aug 06, 2018 at 02:20:03PM +0300, Dan Carpenter wrote:
> On Mon, Aug 06, 2018 at 01:31:32PM +0300, Dan Carpenter wrote:
> > On Mon, Jul 30, 2018 at 02:40:08PM +0200, Norbert Manthey wrote:
> > > Dear Dan,
> > > 
> > > I use my one-line-scan tool [1] to run smatch against non-kernel
> > > projects. However, for Xen I still use -p=kernel, to have all the
> > > analysis enabled. I did not write an evaluation routine to present the
> > > defects or statistics for smatch in a nice way, but smatch can be
> > > invoked. For the latest Xen, smatch (actually sparse) seems to struggle
> > > with the attribute __pointer__ token, as that's not defined.
> > > 
> > > A typical invocation for smatch would look like the following:
> > > 
> > > export SMATCH_EXTRA_ARG="-p=kernel --file-output"
> > > one-line-scan -o SMATCH --smatch --no-gotocc --no-analysis \
> > >   -- make xen -j $(nproc) -B
> > > 
> > > I will look into using the debug info next, and see how taint
> > > information is propagated.
> > > 
> > 
> > I tried use one-line-scan but I didn't want to install it in my $PATH so
> > I couldn't figure out how to make it work...
> > 
> 
> I got one-line-scan to work I think but it still only built those three
> files.  :(
> 

I was just looking for the output in the wrong place...  one-line-scan
seems to work.  There is a problem with the directory being lost, like
you mentioned.  Also it seems to not be pulling in the header file which
defines noreturn.  I'm working on both things.

regards,
dan carpenter

Re: Smatch for Xen

[Dan Carpenter]

On Mon, Aug 06, 2018 at 03:27:11PM +0200, Norbert Manthey wrote:
> Thanks a lot. I am currently out of the office, and might be able to
> respond once in a while. If required, I coukd get more details to help you
> by pulling in colleagues.
> 
> If you have anything that i could improve wrt one-line-scan, please let me
> know.
> 

The --file-output option seems to be broken for xen, but it's also
unnecessary if you're using one-line-scan because the output is already
separated by file.

What would help me is if the strored files like:
SMATCH/smatch/results/xen_arch_x86_pv_ro-page-fault.c
only store stdout and not stderr.

Of course, you'd prefer to not have any stderr output, but otherwise I'm
not interested in it.  It just corrupts my stdout lines.

regards,
dan carpenter

Re: Smatch for Xen

[Norbert Manthey]

Dear Dan,

I just split the output in one-line-scan, and also use your cgcc wrapper
by now. Furthermore, I log all calls to cgcc so that replaying single
calls is easy now. The relevant info is logged in the file

SMATCH/smatch/smatch-preprocess.log

However, I do not see a reason not to use the --file-output flag, in
case you are more used to that. That should simply result in my output
files being empty, but that's fine. This way, your tooling should work,
i.e. collecting all the .smatch files should behave as in case of
working with the kernel.

If there is anything else I can help with, please let me know. I would
love to use your taint analysis for Xen as well.

Best,
Norbert

On 08/06/2018 03:54 PM, Dan Carpenter wrote:
> On Mon, Aug 06, 2018 at 03:27:11PM +0200, Norbert Manthey wrote:
>> Thanks a lot. I am currently out of the office, and might be able to
>> respond once in a while. If required, I coukd get more details to help you
>> by pulling in colleagues.
>>
>> If you have anything that i could improve wrt one-line-scan, please let me
>> know.
>>
> 
> The --file-output option seems to be broken for xen, but it's also
> unnecessary if you're using one-line-scan because the output is already
> separated by file.
> 
> What would help me is if the strored files like:
> SMATCH/smatch/results/xen_arch_x86_pv_ro-page-fault.c
> only store stdout and not stderr.
> 
> Of course, you'd prefer to not have any stderr output, but otherwise I'm
> not interested in it.  It just corrupts my stdout lines.
> 
> regards,
> dan carpenter
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: Smatch for Xen

[Dan Carpenter]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Mon, Aug 13, 2018 at 04:25:46PM +0200, Norbert Manthey wrote:
> Dear Dan,
> 
> I just split the output in one-line-scan, and also use your cgcc wrapper
> by now. Furthermore, I log all calls to cgcc so that replaying single
> calls is easy now. The relevant info is logged in the file
> 
> SMATCH/smatch/smatch-preprocess.log
> 
> However, I do not see a reason not to use the --file-output flag, in
> case you are more used to that. That should simply result in my output
> files being empty, but that's fine. This way, your tooling should work,
> i.e. collecting all the .smatch files should behave as in case of
> working with the kernel.
> 
> If there is anything else I can help with, please let me know. I would
> love to use your taint analysis for Xen as well.
>

Sorry for all this headache.

Yeah.  You don't need --fileoutput if you're using one-line-scan.  But
one-line-scan mixes stdout and stderr which doesn't work for Smatch.  We
only want stdout.

I've just pushed some changes which should help a bit.  And I'm
attaching some scripts to run Smatch on xen.  You're going to want to
change the SCRIPT_DIR in build_xen_data.sh and it assumes that
one-line-scan is in the ../one-line-scan/.  Also you need to save the
script in path/to/xen/../  Sorry, it's not very beautiful.

regards,
dan carpenter


[-- Attachment #2: build_xen_data.sh --]
[-- Type: application/x-sh, Size: 1845 bytes --]

[-- Attachment #3: check.sh --]
[-- Type: application/x-sh, Size: 374 bytes --]

Re: Smatch for Xen

[Dan Carpenter]

Ahh...  Never mind.  My mistake.  It should have just been:

	cat SMATCH/smatch/results/*.c > smatch_warns.txt

The next problem is that I don't seem to be pulling in the
include/xen/compiler.h header file...

regards,
dan carpenter

Re: Smatch for Xen

[Norbert Manthey]

Thanks a lot! I used your scripts and compiled Xen now, as well as
created the data base for it. As I am interested in analysis that is run
for the kernel, I also asked the tool to name the project "kernel", as
that enabled this analysis (e.g. the spectre analysis).

I called the build_xen_data.sh scripts multiple times on an upstream Xen
release branch, and the number of warnings did not increase, while for
the Linux kernel the number of warnings would increase, e.g. warnings
that depend on the taint analysis like the spectre analysis. Is that
expected, and is there a way to improve that for Xen?

Best,
Norbert

On 08/13/2018 08:31 PM, Dan Carpenter wrote:
> Ahh...  Never mind.  My mistake.  It should have just been:
> 
> 	cat SMATCH/smatch/results/*.c > smatch_warns.txt
> 
> The next problem is that I don't seem to be pulling in the
> include/xen/compiler.h header file...
> 
> regards,
> dan carpenter
> 
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: Smatch for Xen

[Dan Carpenter]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

On Tue, Aug 14, 2018 at 03:27:43PM +0200, Norbert Manthey wrote:
> Thanks a lot! I used your scripts and compiled Xen now, as well as
> created the data base for it. As I am interested in analysis that is run
> for the kernel, I also asked the tool to name the project "kernel", as
> that enabled this analysis (e.g. the spectre analysis).
> 
> I called the build_xen_data.sh scripts multiple times on an upstream Xen
> release branch, and the number of warnings did not increase, while for
> the Linux kernel the number of warnings would increase, e.g. warnings
> that depend on the taint analysis like the spectre analysis. Is that
> expected, and is there a way to improve that for Xen?
>

Yeah.  I just noticed that as well.  I've added the --db-file= option.
See the new attached build scripts.

I'm going to make xen it's own project for the purposes of
check_user_data2.c.  Which functions should set the data as tainted?
Like copy_from_user() in the kernel.  Is it really just the same
functions?

I wish I could figure out which version of GCC smatch is saying it is so
I could sort out why the build fails.  It's parsing compiler.h wrong.

regards,
dan carpenter



[-- Attachment #2: build_xen_data.sh --]
[-- Type: application/x-sh, Size: 1918 bytes --]

[-- Attachment #3: check.sh --]
[-- Type: application/x-sh, Size: 410 bytes --]

Re: Smatch for Xen

[Norbert Manthey]

Oh, that's nice. I'll play with the new script.

Concerning the copy from user functions, I have a few patches locally to
get the functions into the tool, which I just have to make a little
nicer before sharing. I will post them once done. I found the
"copy_from_guest" string also at other places, as well as matching
syscalls which come with a user controllable argument. The patches
should cover all those.

Concerning the project name, I'd love to enable all of the kernel
analysis for Xen as well, as allocation, locking, taint and all the
others are similarly important for both projects. I spotted a few places
where the Kernel project name is treated specially (or more extensively
than generic projects), so it felt most simple to just call the project
kernel as well.

Is the parsing performed by smatch, or by sparse? Eventually it's good
enough to add a "-D __GNUC__=5" to the command line to pretend being a
recent compiler? The compile.h file seems to care about version 4 only,
AFAICT.

Best,
Norbert

On 08/14/2018 04:21 PM, Dan Carpenter wrote:
> On Tue, Aug 14, 2018 at 03:27:43PM +0200, Norbert Manthey wrote:
>> Thanks a lot! I used your scripts and compiled Xen now, as well as
>> created the data base for it. As I am interested in analysis that is run
>> for the kernel, I also asked the tool to name the project "kernel", as
>> that enabled this analysis (e.g. the spectre analysis).
>>
>> I called the build_xen_data.sh scripts multiple times on an upstream Xen
>> release branch, and the number of warnings did not increase, while for
>> the Linux kernel the number of warnings would increase, e.g. warnings
>> that depend on the taint analysis like the spectre analysis. Is that
>> expected, and is there a way to improve that for Xen?
>>
> 
> Yeah.  I just noticed that as well.  I've added the --db-file= option.
> See the new attached build scripts.
> 
> I'm going to make xen it's own project for the purposes of
> check_user_data2.c.  Which functions should set the data as tainted?
> Like copy_from_user() in the kernel.  Is it really just the same
> functions?
> 
> I wish I could figure out which version of GCC smatch is saying it is so
> I could sort out why the build fails.  It's parsing compiler.h wrong.
> 
> regards,
> dan carpenter
> 
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: Smatch for Xen

[Dan Carpenter]

On Tue, Aug 14, 2018 at 04:33:15PM +0200, Norbert Manthey wrote:
> Oh, that's nice. I'll play with the new script.
> 
> Concerning the copy from user functions, I have a few patches locally to
> get the functions into the tool, which I just have to make a little
> nicer before sharing. I will post them once done.

Forget about making it nice.  Just send it.  :)

> I found the
> "copy_from_guest" string also at other places, as well as matching
> syscalls which come with a user controllable argument. The patches
> should cover all those.

In the kernel, syscalls should be covered.  Historically, it does matter
how the kernel is configured, but hopefully we've fixed those bugs.
Also we keep changing the SYS_CALL macros, so I can't swear that all
versions work.

regars,
dan carpenter

Re: Smatch for Xen

[Norbert Manthey]

Alright, the patches are out. The list is not complete, but it's a start
that should allow to get the first taint information for Xen as well. I
hope they make sense. Given my limited experience with smatch, I might
have made mistakes.

I spotted limits during compilation, and increased a few. I guess there
are more. I'll play with it and might increase some others eventually,
to get more coverage.

Best,
Norbert

On 08/14/2018 04:52 PM, Dan Carpenter wrote:
> On Tue, Aug 14, 2018 at 04:33:15PM +0200, Norbert Manthey wrote:
>> Oh, that's nice. I'll play with the new script.
>>
>> Concerning the copy from user functions, I have a few patches locally to
>> get the functions into the tool, which I just have to make a little
>> nicer before sharing. I will post them once done.
> 
> Forget about making it nice.  Just send it.  :)
> 
>> I found the
>> "copy_from_guest" string also at other places, as well as matching
>> syscalls which come with a user controllable argument. The patches
>> should cover all those.
> 
> In the kernel, syscalls should be covered.  Historically, it does matter
> how the kernel is configured, but hopefully we've fixed those bugs.
> Also we keep changing the SYS_CALL macros, so I can't swear that all
> versions work.
> 
> regars,
> dan carpenter
> 
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: Smatch for Xen

[Dan Carpenter]

I have an issue where the output is getting a bit jumbled when I build
with --info.

/home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c:4777 sh_audit_fl1_table__guest_2() SQL_caller_info: insert into caller_info values ('/home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c', 'sh_audit_fl1_table__guest_2', 'guest_index', %CALL_ID%, 1, 0, -1, '%call_marker%', /shadow/multi.c:3340 sh_page_fault__guest_4() SQL_caller_info: insert into caller_info values ('/home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c', 'sh_page_fault__guest_4', 'sh_audit_gw', %CALL_ID%, 1, 1001, 0, '$->domain->arch.paging.shadow.has_fast_mmio_entries', '1');

It's mixing line 4777 with 3340.

regards,
dan carpenter

Re: Smatch for Xen

[Norbert Manthey]

I see. I assume smatch does not print output in parallel, so that mix
results from one-line-scan compiling the same file multiple times, and
those calls compete wrt writing to that file.

As the output might be broken, could we agree on using the --file-output
option for now, and I see how I can fix the mixed output problem best?

Best,
Norbert

On 08/15/2018 11:03 AM, Dan Carpenter wrote:
> I have an issue where the output is getting a bit jumbled when I build
> with --info.
> 
> /home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c:4777 sh_audit_fl1_table__guest_2() SQL_caller_info: insert into caller_info values ('/home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c', 'sh_audit_fl1_table__guest_2', 'guest_index', %CALL_ID%, 1, 0, -1, '%call_marker%', /shadow/multi.c:3340 sh_page_fault__guest_4() SQL_caller_info: insert into caller_info values ('/home/dcarpenter/progs/src/xen/xen/xen/arch/x86/mm/shadow/multi.c', 'sh_page_fault__guest_4', 'sh_audit_gw', %CALL_ID%, 1, 1001, 0, '$->domain->arch.paging.shadow.has_fast_mmio_entries', '1');
> 
> It's mixing line 4777 with 3340.
> 
> regards,
> dan carpenter
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B