linux-kernel - Re: 3.12 to 3.13 boot regression bisected

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, 5 Aug 2014 09:45:42 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	P J P <ppandit@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16

On Tue, 05 Aug, at 10:02:42AM, Bruno Prémont wrote:
> 
> I tried in setup_arch(), but system still keeps rebooting.
> 
> Working backwards I got to x86_64_start_kernel() in
> arch/x86/kernel/head64.c but system is still rebooting.
 
Thanks for doing this. I'm sure it was a major PITA ;-)

> Not sure what happens before x86_64_start_kernel() is called, it seems
> to be called from ASM code in arch/x86/kernel/head_64.S.
 
Yep. Roughly the code flow goes like this (chronologically),

  efi_pe_entry()	[arch/x86/boot/compressed/head_64.S]
    efi_main()		[arch/x86/boot/compressed/eboot.c]
  startup_64		[arch/x86/kernel/head_64.S]
  secondary_startup64	[arch/x86/kernel/head_64.S]
  x86_64_start_kernel()	[arch/x86/kernel/head64.c]

> > Meanwhile I'm going to go and stare at the EFI boot stub code and
> > instrument OVMF to check for more memory corruption bugs like the one
> > Michael found in commit c7fb93ec51d4 ("x86/efi: Include a .bss section
> > within the PE/COFF headers").
> 
> If there are places between exit_boot() in
> arch/x86/boot/compressed/eboot.c and x86_64_start_kernel() where I
> should include such loops, please tell!

I guess we need to verify efi_main() actually exits correctly. So a
while (1); loop at the end of that function would be useful.

Assuming that does actually hang, you get the fun of rummaging around in
the early assembly code, where you can use something like this,

bruno:
	hlt
	jmp bruno

to try and force a hang.

Could you also attach your .config? In particular I'm wondering whether
you've got CONFIG_RELOCATBLE enabled.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/