linux-kernel - Re: [RFC 12/16] kgr: add tools

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140506110324.GC15033@xo-6d-61-c0.localdomain>
Date:	Tue, 6 May 2014 13:03:24 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	linux-kernel@...r.kernel.org, jirislaby@...il.com,
	Vojtech Pavlik <vojtech@...e.cz>, Michael Matz <matz@...e.de>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [RFC 12/16] kgr: add tools

On Wed 2014-04-30 16:30:45, Jiri Slaby wrote:
> These are a base which can be used for kgraft patch generation.
> 
> The code was provided by Michael

Should Michael Matz sign it off, then?

> Signed-off-by: Jiri Slaby <jslaby@...e.cz>
> Cc: Michael Matz <matz@...e.de>

>  tools/kgraft/app.c               |   35 +
>  tools/kgraft/app.h               |    7 +

The app is just a dummy to test this on?

> +	./dwarf-inline-tree app.o
> +	@echo "inline pairs"
> +	./dwarf-inline-tree app.o | perl it2rev.pl
> +	@echo "extract stuff"
> +	./objcopy-hacked --strip-unneeded -j .doesntexist. --keep-symbols symlist app.o app-extract.o

Instead of providing local copy of objcopy, should some patch be pushed to FSF?

> +will build most of them, and the check target contains example invocations.
> +The only thing not built automatically is the hacked objcopy (objcopy-hacked),
> +as usually the necessary binutils headers aren't installed.  You'll
> +have to have (recent) binutils sources, apply the patch objcopy.diff
> +and build it yourself.

Ok, I think it should.

> +The seeding symbol list currently needs to come from a human.  It's probably
> +feasible to generate that list for most cases by interpreting a kernel
> +diff.  Binary comparison should _not_ be used to generate it.

And then we reach singularity, because computers will now be able to program
themselves? :-).


> +int global_data;
> +
> +static void __attribute__((noinline)) in_app (void)

in_app(.

> +int main ()

main(int argc, int argv[])

And add a comment that this is dummy app for objdump testing?

> +{
> +  in_app_global();
> +  second_file ();

file(.

> @@ -0,0 +1,7 @@
> +static inline void __attribute__((always_inline)) in_app_inline (void)
> +{
> +  static int local_static_data;
> +  printf ("in_app_inline: %d\n", local_static_data++);
> +}
> +
> +void second_file (void);

Some more spaces before ( need to be deleted.


> +static int __init kgr_patcher_init(void)
> +{
> +        /* removing not supported (yet?) */
> +        __module_get(THIS_MODULE);
> +        /* +4 to skip push rbb / mov rsp,rbp prologue */

What +4 ?

> --- /dev/null
> +++ b/tools/kgraft/dwarf-inline-tree.c
> @@ -0,0 +1,544 @@

GPL, authors would be cool here.


> +#define string char*
> +#include "dwarf_names.h"
> +#undef string

Ouch.

> +    attrib = attr_in;
> +    atname = get_AT_name(dbg, attr);
> +
> +    tres = dwarf_whatform (attrib, &form, &err);
> +    if (tres != DW_DLV_OK)
> +	print_error (dbg, "dwarf_whatform", tres, err);
> +    printf("\t\t%-28s%s\t", atname, get_FORM_name (dbg, form));
> +    /* Don't move over the attributes for the top-level compile_unit
> +     * DIEs.  */
> +    if (tag == DW_TAG_compile_unit)
> +      {
> +	printf ("\n");
> +	return;
> +      }

Is this inherited from GNU code?

> +	case DW_AT_allocated:
> +		if (ellipsis)
> +			return "allocated";
> +		else
> +			return "DW_AT_allocated";
> +	case DW_AT_associated:
> +		if (ellipsis)
> +			return "associated";
> +		else
> +			return "DW_AT_associated";

I have strong feeling that this code is autogenerated, or should be autogenerated. Not 
suitable for kernel git.

Also I believe patch for objdump is best reviewed at GNU mailing lists, and not suitable
for kernel git.

Best regards,
										Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/