linux-kernel - Re: Vmware crashes if compress/misc.c scrolls?

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]

Message-ID: <46B48ADF.9050006@vmware.com>
Date:	Sat, 04 Aug 2007 07:19:11 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Andi Kleen <ak@...e.de>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Iouri Kharon <bc-info@...x.cabel.net>, syslinux@...or.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sahil Rihan <srihan@...are.com>
Subject: Re: Vmware crashes if compress/misc.c scrolls?

Andi Kleen wrote:
>> In the boot decompressor for the kernel in the image Iouri provided, I
>>     
>
> 32bit or 64bit image?
>
>   
>> As you can plainly see, the call to memcpy (which is redefined in
>> boot/compressed/misc.c) is made using stack calling convention.
>> Unfortunately, the compiler generated the memcpy function itself using
>> regparm(3) convention.  I am guessing this happened because a leftover
>>     
>
> I can't find any here grepping .i files and includes. None of the memcpy
> prototypes in include have a __fastcall
>
> Are you sure this still happens in mainline?
>
> When I look at my scroll it also looks correct:
>
>       c0:       0f af f8                imul   %eax,%edi
>       c3:       01 c0                   add    %eax,%eax
>       c5:       89 c2                   mov    %eax,%edx
>       c7:       01 f2                   add    %esi,%edx
>       c9:       89 45 f0                mov    %eax,0xfffffff0(%ebp)
>       cc:       89 f0                   mov    %esi,%eax
>       ce:       89 f9                   mov    %edi,%ecx
>       d0:       e8 7b ff ff ff          call   50 <memcpy>
>
>
>   
>> Does anyone recall compiler problems (I noticed this VM was booting a
>> 64-bit kernel, 
>>     
>
> Ok 64bit, that was 32bit above. 
>
> Since some time the decompressor is 64bit and 64bit always uses 
> regparms. 64bit Scroll is ok too:
>
>      92:       0f af eb                imul   %ebx,%ebp
>       95:       01 db                   add    %ebx,%ebx
>       97:       48 63 f3                movslq %ebx,%rsi
>       9a:       4c 01 ee                add    %r13,%rsi
>       9d:       89 ea                   mov    %ebp,%edx
>       9f:       e8 9c ff ff ff          callq  40 <memcpy>
>
>
>   
>> but the decompressor was 32-bit code, 
>>     
>
> That must be a old kernel.
>
> Can you people please verify this all still happens with a mainline or
> 2.6.22 kernel? 
>
>   
>> so perhaps at some  
>> time the 64-bit makefile or toolchain for Linux had some kind of
>> compiler bug).
>>     
>
> I'm not aware of any such bugs.
>   

It was 2.6.21.4, so it is fairly recent, but with 32-bit decompress 
stage.  GCC was 4.2.0.

Sounds like a gcc bug, to me.

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