linux-kernel - Re: VMI broken on tip/master...

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:	Mon, 16 Mar 2009 15:42:04 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: VMI broken on tip/master...

On Sat, 2009-03-14 at 16:45 -0700, Jeremy Fitzhardinge wrote:
> Alok Kataria wrote:
> > Hi Peter, 
> >
> > I was seeing a early fault when running tip/master with VMI enabled on
> > VMware platform. 
> > This early fault was in the vmi_patch code where we are applying
> > paravirt_alternatives. After some trials i noticed that this is
> > reproducible only with CONFIG_TRACING. With that disabled my VM boots
> > again. 
> >
> > I started a git bisect after that, and git pointed to this as the bad
> > commit
> >
> > commit 6cc3c6e12bb039047974ad2e7e2d46d15a1b762f
> >     trace_clock: fix preemption bug
> >
> > I then reverted that commit from tip/master and the system did boot. 
> > But I fail to understand how this simple patch would be causing things
> > to fail in VMI. Any ideas ?
> >   
> 
> Nope.  My first guess is that this is a misbisection, but the fact that 
> reverting helps tends to undermine that diagnosis.
> 
> What crash are you seeing?  What kind of fault?  At what instruction?  

It being a early fault, nothing is printed on the console the system
just stays stuck in this early_fault code in arch/x86/kernel/head_32.S

I don't understand why is this not printing anything at this early fault
though, the system just enters the hlt_loop and stays there.

> Doing what?  It's a bit hard to tell what you're actually seeing.
I did some more debugging and I think i know what the problem is 
The objdump for trace_clock_local looks like this

c1070c24 <trace_clock_local>:
c1070c24:       55                      push   %ebp
c1070c25:       89 e5                   mov    %esp,%ebp
c1070c27:       53                      push   %ebx
c1070c28:       83 ec 08                sub    $0x8,%esp
c1070c2b:       ff 15 5c 87 3d c1       call   *0xc13d875c
c1070c31:       ba 64 87 3d c1          mov    $0xc13d8764,%edx
c1070c36:       89 45 f4                mov    %eax,0xfffffff4(%ebp)
c1070c39:       ff 12                   call   *(%edx)		<<=====*
c1070c3b:       e8 cd 68 f9 ff          call   c100750d <sched_clock>
c1070c40:       89 c1                   mov    %eax,%ecx
c1070c42:       8b 45 f4                mov    0xfffffff4(%ebp),%eax
c1070c45:       ff 15 60 87 3d c1       call   *0xc13d8760

Notice instruction on c1070c39 we have "call *(edx)",
edx was just loaded with the address for the paravirt call.
when we try to replace that to a call to vmi specific function, maybe we
hit a BUG_ON(len < 5) in vmi's patch_internal code, because now the
instruction length is less than 5.

Is there is a way to get GCC to not do such fancy tricks, and instead do
a direct "call 0xc13d8764"  ?

Thanks,
Alok
> 
> Does reverting the text_poke() changes make a difference?
> 
>     J

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