Xen devel - Oct 2006 - RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining instruction address needs to mask to 32 bits

> -----Original Message-----
> From: xen-changelog-bounces@lists.xensource.com 
> [mailto:xen-changelog-bounces@lists.xensource.com] On Behalf 
> Of Xen patchbot-unstable
> Sent: 29 September 2006 13:50
> To: xen-changelog@lists.xensource.com
> Subject: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining 
> instruction address needs to mask to 32 bits
> 
> # HG changeset patch
> # User kfraser@localhost.localdomain
> # Node ID 792fb641ea7b2a7bdd65ac3c959f92b7528e157a
> # Parent  e229687561cff6d4daa0548c746c07e549bbc0ca
> [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
> if not running in 64-bit mode.
> Signed-off-by: Keir Fraser <keir@xensource.com>
> ---
>  xen/arch/x86/hvm/svm/emulate.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff -r e229687561cf -r 792fb641ea7b xen/arch/x86/hvm/svm/emulate.c
> --- a/xen/arch/x86/hvm/svm/emulate.c	Fri Sep 29 11:25:25 2006 +0100
> +++ b/xen/arch/x86/hvm/svm/emulate.c	Fri Sep 29 11:50:51 2006 +0100
> @@ -341,7 +341,11 @@ unsigned long svm_rip2pointer(struct vmc
>       * %cs is update, but fortunately, base contain the 
> valid base address
>       * no matter what kind of addressing is used.
>       */
> -    return vmcb->cs.base + vmcb->rip;
> +    unsigned long p = vmcb->cs.base + vmcb->rip;
> +    if (!(vmcb->cs.attributes.fields.l && vmcb->efer &
EFER_LMA))
> +        return (u32)p; /* mask to 32 bits */
> +    /* NB. Should mask to 16 bits if in real mode or 16-bit 
> protected mode. */
Actually, no. On a 8086, the address is 20 bits, 80286 would have 24
address bits and 32-bits in a 386 onwards. Real-mode (without trickery)
can''t generate an address much higher than 20 bits [0xFFFF0+0xFFFF is
just over 20 bits, and it depends on the state of the A20-gate [do we
simulate that anywhere?] whether this is masked to near zero or just
over 1MB). Since big realmode only really works for data segments (it''s
hard to avoid the CS segment being reloaded when you go back to
real-mode from protected mode - and should the processor take an
interrupt, it''s game-over on the "big code-segment").

So as a conclusion, I think the comment on masking 16-bit modes is
incorrect - any code that is INTENDED to run on a 286 and still can be
run on anything better would automatically use the 286 addressing which
automatically limits the segment registers base address + limit to
24-bits with no wrap-around - or it would break on a 386, and they would
have been around long enough that most people have fixed the code... ;-)

--
Mats

> +    return p;
>  }
>  
>  
> 
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@lists.xensource.com
> http://lists.xensource.com/xen-changelog
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/06 11:34, "Petersson, Mats" <Mats.Petersson@amd.com>
wrote:
> Actually, no. On a 8086, the address is 20 bits, 80286 would have 24
> address bits and 32-bits in a 386 onwards. Real-mode (without trickery)
> can''t generate an address much higher than 20 bits [0xFFFF0+0xFFFF
is
> just over 20 bits, and it depends on the state of the A20-gate [do we
> simulate that anywhere?] whether this is masked to near zero or just
> over 1MB). Since big realmode only really works for data segments
(it''s
> hard to avoid the CS segment being reloaded when you go back to
> real-mode from protected mode - and should the processor take an
> interrupt, it''s game-over on the "big code-segment").
> 
> So as a conclusion, I think the comment on masking 16-bit modes is
> incorrect - any code that is INTENDED to run on a 286 and still can be
> run on anything better would automatically use the 286 addressing which
> automatically limits the segment registers base address + limit to
> 24-bits with no wrap-around - or it would break on a 386, and they would
> have been around long enough that most people have fixed the code... ;-)
Doesn''t it depend on the D flag in the hidden CS segment state? If D==0
then
should use IP instead of EIP (i.e., mask to 16 bits)? I agree that this
would involve masking eip before adding to the base, rather than masking to
16 bits after adding to the base, so my comment is wrong either way. As a
side note, updates to the program counter would also not affect the high 16
bits of EIP if D==0, right?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: 02 October 2006 12:42
> To: Petersson, Mats; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] 
> [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
> 
> On 2/10/06 11:34, "Petersson, Mats"
<Mats.Petersson@amd.com> wrote:
> 
> > Actually, no. On a 8086, the address is 20 bits, 80286 would have 24
> > address bits and 32-bits in a 386 onwards. Real-mode 
> (without trickery)
> > can''t generate an address much higher than 20 bits 
> [0xFFFF0+0xFFFF is
> > just over 20 bits, and it depends on the state of the 
> A20-gate [do we
> > simulate that anywhere?] whether this is masked to near zero or just
> > over 1MB). Since big realmode only really works for data 
> segments (it''s
> > hard to avoid the CS segment being reloaded when you go back to
> > real-mode from protected mode - and should the processor take an
> > interrupt, it''s game-over on the "big
code-segment").
> > 
> > So as a conclusion, I think the comment on masking 16-bit modes is
> > incorrect - any code that is INTENDED to run on a 286 and 
> still can be
> > run on anything better would automatically use the 286 
> addressing which
> > automatically limits the segment registers base address + limit to
> > 24-bits with no wrap-around - or it would break on a 386, 
> and they would
> > have been around long enough that most people have fixed 
> the code... ;-)
> 
> Doesn''t it depend on the D flag in the hidden CS segment 
> state? If D==0 then
> should use IP instead of EIP (i.e., mask to 16 bits)? I agree 
> that this
> would involve masking eip before adding to the base, rather 
> than masking to
> 16 bits after adding to the base, so my comment is wrong 
> either way. As a
> side note, updates to the program counter would also not 
> affect the high 16
> bits of EIP if D==0, right?
Ah, good point - however, the processor should do this right for the
function in question [we''re not adding anything to the rIP in the
relevant code, besides adding the base of the segment, which is not
directly related to the bitsize of the current mode]. 

Where we''re adding to EIP we probably should take this into acocunt -
although most code wouldn''t naturally wrap the IP (in fact, I think
it''s
a fault to do so - but I can''t confirm that from any of my books), so
it''s probably a very obscure corner-case - but it''s probably a
bit
nightmarish to debug so it''s possibly better to have code that deals
with it correctly. I''ll figure out if it''s a fault or
"wrap" that is the
correct operation first... 

--
Mats
> 
>  -- Keir
> 
> 
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/06 12:56, "Petersson, Mats" <Mats.Petersson@amd.com>
wrote:
> Where we''re adding to EIP we probably should take this into
acocunt -
> although most code wouldn''t naturally wrap the IP (in fact, I
think it''s
> a fault to do so - but I can''t confirm that from any of my books),
so
> it''s probably a very obscure corner-case - but it''s
probably a bit
> nightmarish to debug so it''s possibly better to have code that
deals
> with it correctly. I''ll figure out if it''s a fault or
"wrap" that is the
> correct operation first...
I think it faults on AMD and silently wraps on Intel. One of the Xbox hacks
relies on this ''feature'' to break into the secure bootstrap
sequence. I
doubt anyone legitimately relies on it so I''m not too concerned about
this
case.

Also, back to my original point, it''s probably a good idea to mask the
high
bits of RIP when in 16-bit mode. I doubt that the switch from 32- to 16-bit
mode guarantees to clear those high bits. Or does it?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel