linux-kernel - Re: [GIT PULL] x86 fixes

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:	Tue, 23 Sep 2014 10:18:07 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Matt Fleming <matt.fleming@...el.com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Roy Franz <roy.franz@...aro.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes

On 23 September 2014 09:20, Matt Fleming <matt.fleming@...el.com> wrote:
> On Tue, 2014-09-23 at 07:58 +0200, Ingo Molnar wrote:
>>
>> So if it's the GOT fixup then I feel the safest option is to
>> revert 9cb0e394234d straight away, and then to do a functional
>> revert of f23cf8bd5c1f49 as a separate step, perhaps via
>> something really crude like:
>>
>>    #include "../..../drivers/firmware/efi/libstub/efi-stub-helper.c"
>>
>> or so. (Maybe someone else can think of something
>> cleaner/simpler, because this method is really ugly, as we'd have
>> to #include the whole libstub library into eboot.c AFAICS...)
>
> Yeah, I think at this point in the release cycle it would be safest to
> revert back to the original scheme of #including the .c files. I'm not

Agreed

> sure if we can do any better in a robust way, i.e. without introducing
> more regressions. Then take a look at doing the boot stub unification
> with fresh eyes (and improved testing) after v3.17.
>
> What I want to avoid is reverting the arm64 side of things too, so I'm
> gonna take a stab at doing the necessary reverts/partial
> reverts/whatever to get x86 back to the pre-merge window boot stub
> duplicated code scheme.
>

The stub unification was already working fine in 3.16, it is the
libstub cleanup I did that is causing this, so we could revert just
all of that if it makes it easier to get this fixed for the release.

Unless your last patch was incorrect (which I don't think it was), the
only way to solve this conclusively is finding a way (i.e., through
visibility=hidden attributes for efi_early etc) to share those symbols
between .o files without introducing any new GOT entries. Anyone in
team x86 that can shed some light on why hidden globals still generate
GOT entries on 32 bit?

It will be difficult for me to keep up with this thread over the next
days, so I have added Leif and Roy on cc. If you need to make any
changes that affect arm64, they should be able to confirm whether it
causes any problems or not.

Thanks,
Ard.
--
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/