Re: [PATCH v1 7/7] tools: add userspace linker table sandbox

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Aug 23, 2016 at 10:28:39PM -0400, Kees Cook escreveu:
> On Tue, Aug 23, 2016 at 10:30 AM, Arnaldo Carvalho de Melo
> <acme@redhat.com> wrote:
> > Em Mon, Aug 22, 2016 at 05:28:42PM -0700, H. Peter Anvin escreveu:
> >> On August 22, 2016 5:07:39 PM PDT, "Luis R. Rodriguez" <mcgrof@kernel.org> wrote:
> >> >On Fri, Aug 19, 2016 at 03:31:47PM -0700, Kees Cook wrote:

> >> >> Aren't a bunch of these files exact duplicates of the headers in
> >> >include/linux?

> >> >Indeed... This a userspace tools/ architecture decision that was made
> >> >long ago, so its not up to me, I am just following the strategy
> >> >devised and picked up.  Refer to
> >> >7d7d1bf1d1dabe435ef50efb051724b8664749cb ("perf bench: Copy kernel
> >> >files needed to build mem{cpy,set} x86_64 benchmarks") for an example
> >> >of previous similar work. By sharing header files this enable more
> >> >tools/ to be hacked on.

> >> I think this is a legacy from before the uapi change that should
> >> really be fixed.  If we need to export additional kernel structures
> >> for the tools, we could define a third level of we really need it.

> > No, it is something recent, its just that from time to time files that
> > tools/ included from outside, i.e. from the kernel sources, made tools/
> > break, so after discussion with Linus and Ingo[1], it was decided we would

> This [1] reference seems missing. I'm curious to see the thread. I

I added the '[1]', went to look for the discussion yesterday, but it was
a private conversation with ~15 people, bummer, but the one below has
Ingo describing it in another occasion where a new utility got added to
tools/, objtool:

  https://lkml.kernel.org/r/20160309183945.GA17956@gmail.com

And yeah, I started using stuff directly from the kernel, breakage took
place, we changed course.

> wonder if something could be done to just generate the needed headers
> from the canonical locations into the tools/ locations?

Then that would bring possible problems, better to do it manually when
auto-detected.
 
> > grab copies and never more access anything outside tools/ directly.
> >
> > Instead we would check for changes and warn the tools/ developers about
> > it, so that they could check what has changed, that could mean changes
> > should/could be done to tools/ using those headers.
> 
> Is there anything automated in place to notice when these changes happen?

See 791cceb89f7987c0375ff2e8971928a47f62ccae, among others, but it will
amount to something like:

    Changes detected by the tools build system:
    
      $ make -C tools/perf O=/tmp/build/perf install-bin
      make: Entering directory '/home/acme/git/linux/tools/perf'
        BUILD:   Doing 'make -j4' parallel build
--->  Warning: tools/include/uapi/linux/bpf.h differs from kernel <-------
        INSTALL  GTK UI
        CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
      <SNIP>
      $

- Arnaldo