linux-kernel - Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

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, 13 May 2008 15:28:08 +0200
From:	"Robert Kaiser (FH)" <kaiser@...ormatik.fh-wiesbaden.de>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	xen-devel@...ts.xensource.com, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

Am Dienstag 13 Mai 2008 13:48 schrieb Jeremy Fitzhardinge:
> Robert Kaiser (FH) wrote:
> > Hmm, I had to revert to non-PAE operation (using xen 3.2.1) recently in
> > order to get Xen to run under qemu. Does anyone know of another
> > work-around to run Xen/Linux under qemu?
>
> In principle it should work in PAE mode;

I thought so, too, however it doesn't :-(.

> it certainly works in kvm. 
> What problem are you seeing?

Linux crashes just after the message "Freeing unused 
kernel memory: ..." due to dereferencing a bad address.

The following is from the top of my head (if you need more details, let me kow 
and I'll recompile everything with PAE so I can reproduce the problem again 
-- this will take some time though..):

The crash results from a call to do_munmap(). Strangely though, when setting a 
breakpoint at the faulting assembly instruction (I'm using qemu's debug stub 
facility) , the problem disappears: the address being dereferenced (contained 
in register eax) is always a valid one. However, as soon as I remove that 
breakpoint and hit "continue", it does crash again with the crash dump 
showing an eip pointing to where the breakpoint formerly was, and an invalid 
address in eax.

> I think there's a bug in qemu's x86 
> emulation with respect to mis-reporting the eip of an xchg which faults,
> which may be what you're seeing.

The eip that was reported was always the same, and there was no xchg 
instruction at that address. It might have been consistently wrong though 
(how would I figure this out?).

Rob

-- 
Robert Kaiser                    http://wwwvs.informatik.fh-wiesbaden.de
Labor für Verteilte Systeme            kaiser@...ormatik.fh-wiesbaden.de
FH Wiesbaden - University of Applied Sciences     tel: (+49)611-9495-294
Kurt-Schumacher-Ring 18, 65197 Wiesbaden, Germany fax: (+49)611-9495-294
--
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/