linux-kernel - Re: Regression: boot failure on AMD Elan TS-5500

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: <486A921E.2070306@goop.org>
Date:	Tue, 01 Jul 2008 13:22:54 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Sean Young <sean@...s.org>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: Regression: boot failure on AMD Elan TS-5500

Sean Young wrote:
> On Mon, Jun 30, 2008 at 03:42:47PM -0700, H. Peter Anvin wrote:
>   
>> Jeremy Fitzhardinge wrote:
>>     
>>> Maybe it really does require the far jump immediately after setting PE 
>>> in cr0...
>>>
>>> Hm, I don't remember this paragraph being in vol 3a, section 8.9.1 
>>> before.  Is it a recent addition?
>>>
>>>   Random failures can occur if other instructions exist between steps
>>>   3 and 4 above.  Failures will be readily seen in some situations,
>>>   such as when instructions that reference memory are inserted between
>>>   steps 3 and 4 while in system management mode.
>>>
>>>       
>> I don't remember that, either.
>>     
>
> Which document are we talking about? 
>   

*The* document ;)
http://www.intel.com/products/processor/manuals/ specifically, Volume 
3a: System Programming Guide, Part 1. 

Section 8.9.1 describes the steps needed to turn on protected mode 
correctly.  It says that you need to do a far jump or call immediately 
after turning on protected mode.  Linux has not done it immediately, and 
there has been a school of thought that this advice is a workaround for 
some obsolete CPU, and is not something we have to worry about now.

However, the paragraph I quoted was added since the previous release of 
the manual, and so presumably documents a current concern.  
Specifically, the mention of SMM is interesting, because I gather that 
embedded-class processors like the Elan are very SMM-dependent.

>> Sean: could you try the following patch?
>>
>> 	-hpa
>>     
>
>   
>> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
>> index ab049d4..141b6e2 100644
>> --- a/arch/x86/boot/pmjump.S
>> +++ b/arch/x86/boot/pmjump.S
>> @@ -33,6 +33,8 @@ protected_mode_jump:
>>  	movw	%cs, %bx
>>  	shll	$4, %ebx
>>  	addl	%ebx, 2f
>> +	jmp	1f			# Short jump to serialize on 386/486
>> +1:
>>  
>>  	movw	$__BOOT_DS, %cx
>>  	movw	$__BOOT_TSS, %di
>> @@ -40,8 +42,6 @@ protected_mode_jump:
>>  	movl	%cr0, %edx
>>  	orb	$X86_CR0_PE, %dl	# Protected mode
>>  	movl	%edx, %cr0
>> -	jmp	1f			# Short jump to serialize on 386/486
>> -1:
>>  
>>  	# Transition to 32-bit mode
>>  	.byte	0x66, 0xea		# ljmpl opcode
>>     
>
> I'm afraid it doesn't work. Maybe I can find something in the AMD Elan
> documentation. Would a fence make sense?
>   

Not really, but if it fixes the bug it won't hurt anyone else (unless 
older processors treat it as an illegal instruction).

    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/