linux-kernel - Re: vdso_install target broken post-3.15

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:	Wed, 18 Jun 2014 09:09:53 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: vdso_install target broken post-3.15

On Wed, Jun 18, 2014 at 12:22 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>>> Just a heads up: gdb can't debug the vdso on 3.16-rc1.  I filed a bug:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>>>>
>>>> We may need to extend the fake section header hack to all vdso
>>>> versions and stick the ELF notes in there.
>>>
>>> I have a semi-working implementation of a workaround, bit it adds a
>>> fair amount of extra crud to the image, and it's pushing my
>>> configuration past a page boundary.  I suspect that, if we're willing
>>> to abuse the ELF format a bit more, I can get the overhead down,
>>> though.
>>>
>>> Are we okay with regressing here until binutils gets fixed?
>>>
>>
>> Probably not... although I guess it depends just how bad it really is.
>
> AFAICT the only issue is that gdb will fail to find installed debug
> info on systems that install it into .build-id, which AFAIK means
> Fedora and similar users who install kernel RPMs.  This won't effect
> anyone who installs their own kernel, since it never worked correctly
> for those users anyway.

For some reason I thought SLES/OpenSUSE did build-id as well.

> Fortunately, Fedora ought to be able to update its gdb and/or binutils
> rpm by the time that 3.16 kernel RPMs show up.  Josh, is this
> workable?  In my experience, I've never had a sourceware.org bug

Getting binutils fixed in rawhide typically isn't a problem if the
reporter and upstream are persistent.  Getting it fixed in a more
stable Fedora release is a bit more work and really depends on how
invasive the fix is.

> fixed, but I have had bugzilla.redhat.org bugs fixed.  I'm looking at
> the binutils code, and I'm kind of scared of it.  Also, I don't have
> an FSF copyright assignment on file.
>
> I filed this Fedora bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1110598
>
> Let's see what happens.  Can we give this a little while?

I think that really depends on who all is using build-id for their
debuginfo stuff and how much upstream cares about breaking them.  Even
if it's contained to Fedora derived distros, getting binutils fixed in
RHEL for this is much harder.  I have no idea how SLES/OpenSUSE would
contain this if they are using build-id.

> I wrote this:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/vdso_sections
>
> but it's bad: I'm not allocating space properly, so it doesn't
> reliably build.  Also, it wastes space, and I'd rather just get rid of
> this crap.

The "if/when binutils gets fixed" is really the crux of the issue.
Unless the upstream kernel puts a hard requirement on a fixed binutils
version, we can't really depend on people having a fixed binutils.  If
that code were to get added, it would like stay for a very long time.

josh
--
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/