linux-kernel - Urgent: x86-32 and GNU ld 2.22.52.0.1

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-next>] [day] [month] [year] [list]

Date:	Fri, 18 May 2012 08:56:54 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H.J. Lu" <hjl.tools@...il.com>, Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@...el.com>
Subject: Urgent: x86-32 and GNU ld 2.22.52.0.1

I need an urgent opinion.  It seems we have an epic mess on our hands.

GNU ld 2.22.52.0.1 silently changed the semantics of section-relative
symbols that are part of otherwise empty sections, and silently changes
them to absolute.  We rely on section-relative symbols staying
section-relative, and actually have several sections in the linker
script solely for this purpose.

The postprocessor for the x86-32 kernel, relocs.c, currently doesn't
enforce its audited absolute symbols list.  As part of the
tip:x86/trampoline rework, however, I made it error out rather that
silently producing bad output.

Ingo has found that with this particular version of GNU ld, the error
triggers.  I want to emphasize that this merely catches an error which
the current version of the tool would have allowed to silently go by,
which would have (possibly) caused a failure if the kernel was
subsequently booted in anything but its default location.

There are a few ways we can deal with this, but I think we need to do
one or the other:

1. We can blacklist this version of GNU ld.
2. We can uprev the tool to the one from the tip:x86/trampoline work,
   with error checking, and give it a list of symbols that should
   be relative but may end up as absolute.  We risk build errors for
   some people if the list isn't complete.
3. We do a minimal forward-port of the error checking into the current
   tool.
4. We add to the list of relative symbols in the current version of
   the tool without adding the error checking.

However, since it seems clear that we're silently producing corrupt
kernels out of the current build, I think we need a fix for this for 3.4.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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