linux-kernel - Re: Unifying x86_64 / Xen init paths and reading hardware

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

Message-ID: <20160116090938.GA32085@pd.tnic>
Date:	Sat, 16 Jan 2016 10:09:38 +0100
From:	Borislav Petkov <bp@...e.de>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Juergen Gross <jgross@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Unifying x86_64 / Xen init paths and reading hardware_subarch
 early

On Fri, Jan 15, 2016 at 05:39:05PM -0800, Luis R. Rodriguez wrote:
> On Fri, Jan 15, 2016 at 4:43 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> >>     for (i = 0; i < sizeof(boot_params); i += 4096)
> >>         early_make_pgtable((unsigned long)params + i);
> >
> >  I'll give this a shot.
> 
> Thanks again for this! It seems to let this boot now! But it does not
> seem to provided the right value. If I use the qemu debug patch as I
> listed before to set this to 5 for kvm, and boot it doesn't come up.
> This can be tested with the qemu debug patch + this debug kernel patch
> which prints it out and resets it from what it finds early.
> 
> If you comment out the boot_params.hdr.hardware_subarch =
> my_hardware_subarch; assignment we get the right value from the
> copy_bootdata() work. I use my_hardware_subarch just as a quick hack
> to test and cache the value early code gets but that I can't print
> early on.

You can always do stupid debug loops:

	while (subarch == <expected_value>)
		rep_nop();

and when your guest stops booting and gdb points you here, then you know
what's going on. You can then dump interesting stuff too from gdb.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--