linux-kernel - Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

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: <CACT4Y+Y6+S9E+vJUZzWxyU+0M5i3L_+8knhxFtfaWYkdN5Vusg@mail.gmail.com>
Date:	Tue, 8 Mar 2016 16:35:42 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Wang Nan <wangnan0@...wei.com>, Ingo Molnar <mingo@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	He Kuang <hekuang@...wei.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Brendan Gregg <brendan.d.gregg@...il.com>,
	Jiri Olsa <jolsa@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Zefan Li <lizefan@...wei.com>, pi3orama@....com
Subject: Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

On Tue, Mar 8, 2016 at 4:29 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Peter Zijlstra <peterz@...radead.org> wrote:
>
>> Here's a thread on syz-kaller:
>>
>>   lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tnyO3w@...l.gmail.com
>>
>> If things have shifted again I'm sure Dmitry is willing to help.
>
> So I tried to install 'go' but it's a _really_ unintuitive tool I have to say.
>
> I installed golang-go on Ubuntu, which gave me a 'go' command:
>
>   triton:~> go version
>   go version go1.5.1 linux/amd64
>
> that was the only step that worked. It's a dead end from that point on:
>
>  triton:~> go get github.com/google/syzkaller
>  package github.com/google/syzkaller: cannot download, $GOPATH not set. For more details see: go help gopath
>
> ok, so lets set GOPATH to the distro src directory:
>
>  triton:~> export GOPATH=/usr/lib/go/src/
>  triton:~> go get github.com/google/syzkaller
>  package github.com/google/syzkaller: mkdir /usr/lib/go/src/src: permission denied
>
> btw., this is what the directory contains:
>
>  triton:~> ls /usr/lib/go/src/
>  all.bash          bootstrap.bash  bytes       compress   debug     flag  html      io            make.bat   nacltest.bash  race.bash  run.bash  strconv  testing  unsafe
>  all.bat           bufio           clean.bash  container  encoding  fmt   image     iostest.bash  Make.dist  net            race.bat   run.bat   strings  text
>  androidtest.bash  buildall.bash   clean.bat   crypto     errors    go    index     log           math       os             reflect    runtime   sync     time
>  archive           builtin         cmd         database   expvar    hash  internal  make.bash     mime       path           regexp     sort      syscall  unicode
>
> so, according to the error message it wants a writable directory. Lets try it that
> way:
>
>  triton:~> mkdir go
>  triton:~>
>  triton:~> export GOPATH=/home/mingo/go/
>  triton:~> go get github.com/google/syzkaller
>  can't load package: package github.com/google/syzkaller: no buildable Go source files in /home/mingo/go/src/github.com/google/syzkaller

Yes, GOPATH needs to be set a writable dir.
You can ignore "can't load package" error. The goal of that step is
checkout syzkaller with all dependencies into correct dirs under
GOPATH. That's already done by now.
Or you can do (/... at the end):
$ go get github.com/google/syzkaller/...
That will checkout and build.
Either way you can continue with the make step.



> looks like someone wants 'Go' to be used as little as possible! ;-)

You probably did not observe recently a noobie trying to build a C
project with sufficiently-complicate-build-system and a bunch of
dependencies that needs to be on specific, unknown revisions, and that
still does not compile with you compiler and does not link with your
linker, and then of course target machine has a wrong glibc version :)