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 08:20:51 +0100
From:	Matt Fleming <matt.fleming@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	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>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [GIT PULL] x86 fixes

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

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