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 07:35:10 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matt Fleming <matt.fleming@...el.com>
Cc:	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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Please pull the latest x86-urgent-for-linus git tree from:
> 
> I only just noticed, but this pull request causes my Sony Vaio 
> laptop to immediately reboot at startup.
> 
> I'm assuming it's one of the efi changes, but I'm bisecting now 
> to say exactly where it happens. It will get reverted.

I've Cc:-ed Matt.

My guess would be one of these two EFI commits:

      * Fix early boot regression affecting x86 EFI boot stub when loading
        initrds above 4GB - Yinghai Lu
    
47226ad4f4cf x86/efi: Only load initrd above 4g on second try

      * Relocate GOT entries in the x86 EFI boot stub now that we have
        symbols with global visibility - Matt Fleming

9cb0e394234d x86/efi: Fixup GOT in all boot code paths

If it's 9cb0e394234d - then it's perhaps a build quirk, or a bug 
in the assembly code. If so then we'd have to revert this, and 
reintroduce another regression, caused by EFI commit 
f23cf8bd5c1f49 in this merge window. The most recent commit is 
easy to revert, the older one not.

If it's 47226ad4f4cf then we'd reintroduce the regression caused 
by 4bf7111f501 in the previous merge window. They both revert 
cleanly after each other - but it might be safer to just revert 
the most recent one.

My guess is that your regression is caused by 47226ad4f4cf.

Sorry about this, the timing is unfortunate.

Thanks,

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

Powered by blists - more mailing lists