Re: [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
> Hi Steffen,
>
> As Avi pointed out, VT requires that SS.RPL == CS.RPL.  We're seeing
> gfxboot fail under KVM because ss = 0x5761 while cs = 0x4004 during
> the transition from real mode to protected mode.  The attached patch
> passes the value of ss through ebx since KVM has to sanitize the value
> of ss to make VT happy.
>
> I've tested this with a remastered Ubuntu Gutsy install CD.  I
> couldn't find the right gfxboot theme for the openSuSE install CD I
> have so I wasn't able to test it.
>
> I suspect that Xen should have a very similar problem as I can't think
> of a possible way to work around this.
>

> diff -ur a/bincode.asm b/bincode.asm
> --- a/bincode.asm	2007-07-24 05:49:46.000000000 -0500
> +++ b/bincode.asm	2007-09-29 22:14:35.000000000 -0500
> @@ -15519,6 +15519,7 @@
>  switch_to_pm:
>  		pushf
>  		push eax
> +		push ebx
>  
>  		mov eax,cr0
>  
> @@ -15534,6 +15535,11 @@
>  		mov word [cs:rm_seg.fs],fs
>  		mov word [cs:rm_seg.gs],gs
>  
> +		;; ss:rpl must equal cs:rpl in PM for VT.  we can't rely on ss
> +		;; maintaining it's value after the transition so we have to
> +		;; pass it in a GP register
> +		mov ebx,ss
> +	
>  		or al,1
>  		o32 lgdt [cs:pm_gdt]
>  		o32 lidt [cs:pm_idt]
> @@ -15546,7 +15552,7 @@
>  		mov ax,pm_seg.prog_d16
>  		mov ds,ax
>  
> -		mov eax,ss
> +		mov eax,ebx
>  		and esp,0ffffh
>  		shl eax,4
>   

This is subtly wrong, I think.  First, note that 'mov eax,ss' only
affects ax, not the high 16 bits.  The note that the original code
happily shifts eax which is half ss, half garbage left by 4 bits and
uses that to generate a 32-bit result.

The reason it worked before was that bits 16-29 of eax are already clear
by virtue of having come from cr0.  But now you're using ebx which
hasn't had that magic clearing.

In your comment to the kvm bug you say that the patch allows you to
boot, so perhaps bits 16-29 of ebx are already clear here, or my
analysis is mistaken.

>  		add esp,eax
> @@ -15557,6 +15563,7 @@
>  		mov fs,ax
>  		mov gs,ax
>  
> +		pop ebx
>  		pop eax
>  		popfw
>  		o16 ret
>   



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/