All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qiaonuohan@cn.fujitsu.com, afaerber@suse.de,
	qemu-stable@nongnu.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] walk_pml4e(): fix abort on bad PML4E/PDPTE/PDE/PTE addresses
Date: Thu, 30 May 2013 09:16:45 -0400	[thread overview]
Message-ID: <20130530091645.08e47dbb@redhat.com> (raw)
In-Reply-To: <51A75122.9020305@redhat.com>

On Thu, 30 May 2013 15:16:18 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

> On 05/30/13 14:59, Luiz Capitulino wrote:
> > On Tue, 28 May 2013 14:19:22 -0400
> > Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > 
> >> The code used to walk IA-32e page-tables, and possibly PAE page-tables,
> >> uses the bit mask ~0xfff to get the next PML4E/PDPTE/PDE/PTE address.
> >>
> >> However, as we use a uint64_t to store the resulting address, that mask
> >> gets expanded to 0xfffffffffffff000 which not only ends up selecting
> >> reserved bits but also selects the XD bit (execute-disable) which
> >> happens to be enabled by Windows 8, causing qemu_get_ram_ptr() to abort.
> >>
> >> This commit fixes that problem by replacing ~0xfff by a correct mask
> >> that only selects the address bit range (ie. bits 51:12).
> >>
> >> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > 
> > Ping? Wen?
> > 
> > Would be nice get a Reviewed-by before merging...
> 
> I didn't miss your submission and did find it OK, I just felt unsure
> about stating so, because "simple" patches like this are prime territory
> to burn someone's R-b's worth (ie. to expose a reviewer's lack of
> information / experience). But hey, what can I lose? The patch does look
> good to me, so

Thank you Laszlo! It's also new territory for me, that's why I'm asking
for reviews (otherwise I'd just sneak it in some pull request :-)

> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> 
> > 
> >> ---
> >>
> >> PS: I (obviously) don't any more core dumps with this patch applied, but
> >>     I couldn't check if the Windows dump is correct (does anyone know
> >>     how to do this?). I did quickly check on Linux though.
> >>
> >>  target-i386/arch_memory_mapping.c | 10 ++++++----
> >>  1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/target-i386/arch_memory_mapping.c b/target-i386/arch_memory_mapping.c
> >> index 844893f..24884bd 100644
> >> --- a/target-i386/arch_memory_mapping.c
> >> +++ b/target-i386/arch_memory_mapping.c
> >> @@ -75,6 +75,8 @@ static void walk_pte2(MemoryMappingList *list,
> >>  }
> >>  
> >>  /* PAE Paging or IA-32e Paging */
> >> +#define PLM4_ADDR_MASK 0xffffffffff000 /* selects bits 51:12 */
> >> +
> >>  static void walk_pde(MemoryMappingList *list, hwaddr pde_start_addr,
> >>                       int32_t a20_mask, target_ulong start_line_addr)
> >>  {
> >> @@ -105,7 +107,7 @@ static void walk_pde(MemoryMappingList *list, hwaddr pde_start_addr,
> >>              continue;
> >>          }
> >>  
> >> -        pte_start_addr = (pde & ~0xfff) & a20_mask;
> >> +        pte_start_addr = (pde & PLM4_ADDR_MASK) & a20_mask;
> >>          walk_pte(list, pte_start_addr, a20_mask, line_addr);
> >>      }
> >>  }
> >> @@ -208,7 +210,7 @@ static void walk_pdpe(MemoryMappingList *list,
> >>              continue;
> >>          }
> >>  
> >> -        pde_start_addr = (pdpe & ~0xfff) & a20_mask;
> >> +        pde_start_addr = (pdpe & PLM4_ADDR_MASK) & a20_mask;
> >>          walk_pde(list, pde_start_addr, a20_mask, line_addr);
> >>      }
> >>  }
> >> @@ -231,7 +233,7 @@ static void walk_pml4e(MemoryMappingList *list,
> >>          }
> >>  
> >>          line_addr = ((i & 0x1ffULL) << 39) | (0xffffULL << 48);
> >> -        pdpe_start_addr = (pml4e & ~0xfff) & a20_mask;
> >> +        pdpe_start_addr = (pml4e & PLM4_ADDR_MASK) & a20_mask;
> >>          walk_pdpe(list, pdpe_start_addr, a20_mask, line_addr);
> >>      }
> >>  }
> >> @@ -249,7 +251,7 @@ int cpu_get_memory_mapping(MemoryMappingList *list, CPUArchState *env)
> >>          if (env->hflags & HF_LMA_MASK) {
> >>              hwaddr pml4e_addr;
> >>  
> >> -            pml4e_addr = (env->cr[3] & ~0xfff) & env->a20_mask;
> >> +            pml4e_addr = (env->cr[3] & PLM4_ADDR_MASK) & env->a20_mask;
> >>              walk_pml4e(list, pml4e_addr, env->a20_mask);
> >>          } else
> >>  #endif
> > 
> > 
> 

  reply	other threads:[~2013-05-30 13:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 18:19 [Qemu-devel] [PATCH] walk_pml4e(): fix abort on bad PML4E/PDPTE/PDE/PTE addresses Luiz Capitulino
2013-05-30 12:59 ` Luiz Capitulino
2013-05-30 13:16   ` Laszlo Ersek
2013-05-30 13:16     ` Luiz Capitulino [this message]
2013-05-30 14:10       ` Andreas Färber
2013-05-30 14:14         ` Luiz Capitulino
2013-05-30 14:22           ` Andreas Färber
2013-05-30 14:25             ` Luiz Capitulino
2013-05-30 14:29 ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130530091645.08e47dbb@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=afaerber@suse.de \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=qiaonuohan@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.