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