linux-kernel - Re: Segmentation fault on all golang executables

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]

Date:	Thu, 12 Jun 2014 11:38:27 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Kui Zhang <kuizhang@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: Segmentation fault on all golang executables

On Thu, Jun 12, 2014 at 10:20 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Thu, Jun 12, 2014 at 9:59 AM, Kui Zhang <kuizhang@...il.com> wrote:
>> Hello,
>>
>> This commit seem to cause Segmentation fault on any of my golang executables.
>
> Well, crap.  It looks like the Go people took my sample vDSO parser...
> and broke it.  WTF were they thinking?  I should have noticed that
> they screwed it up when I was cc'd on this thing:
>
> https://code.google.com/p/go/source/detail?r=56ea40aac72b
>
> but I didn't.  Sorry, everyone.  And the issue isn't even something
> sensibly broken like trying to find vdso symbols in the symbol table.
> No, they're using the size of the SHT_DYNSYM section to deduce the
> number of entries *in the dynamic table*.  This is just completely
> wrong.
>
> But even that's not all.  They borrowed by error handling, so they
> should have silently failed to parse the vdso instead of crashing.
> But then they broke it completely by failing to zero the state, so
> they're just reading from initialized memory.  Grr.
>
> The current offending code is here:
>
> https://code.google.com/p/go/source/browse/src/pkg/runtime/vdso_linux_amd64.c
>
> Since we don't get to break all Go executables, here are two options:
>
> 1. Try to keep the whole symbol table intact.  This is annoying:
> there's a reason I removed it.  The linker script doesn't know how big
> it is, so it's hard to make it compatible with the vvar table.
>
> 2. Write a dummy section table that contains a single empty section of
> type SHT_DYNSYM.  Hopefully the Go runtime will then get far enough to
> fail cleanly.  And they can go and write a real ELF parser or copy my
> reference parser correctly.  (hpa, can you apply my patches to make
> the reference parser 32-bit clean?)

Sigh.

See attached.  It seems to work for me.  Can you test it?  It'll hurt
performance for Go programs, but I don't feel too bad about that.

--Andy

View attachment "0001-x86-vdso-Hack-to-keep-64-bit-Go-programs-working.patch" of type "text/x-patch" (3966 bytes)