Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of resource conflict for OpRegion.

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: firemeteor.guo@xxxxxxxxx [mailto:firemeteor.guo@xxxxxxxxx] On
> Behalf Of G.R.
> Sent: Wednesday, January 09, 2013 10:34 AM
> To: Ross Philipson; Ian Campbell
> Cc: xen-devel; Keir (Xen.org); Jean.guyader@xxxxxxxxx; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of
> resource conflict for OpRegion.
> 
> >> >> More importantly I am pointing out that if
> >> >> you are trying to find out information like the
> location/size/layout
> >> of
> >> >> the IGD OpRegion, you can get that information from the host BIOS.
> >> That
> >> >> sounded like what your original issues centered around. Sorry if I
> >> >> confused things.
> >> >
> >>
> >> Ross, your help is highly appreciated. I think it's not you that
> >> confused things.
> >> The problem comes from my side, I'm far from familiar with all these
> >> ACPI / BIOS related stuff.
> >> I dumped && disassembled the ACPI table. But have no idea how to read
> >> the output...
> >> I attached the DSDT.dsl dumped from my system, in case you would like
> >> to take a quick check.
> >>
> 
> >> Just one more question -- is the layout specific to the bios, or
> common?
> >> I wonder how can we judge the security risk if the layout is not
> >> constant.
> >
> > I would say the layout of the IGD stuff is common per the Intel spec
> for it and the OEMs have to follow that spec when writing the BIOS. But
> it could change for newer hardware (with a new rev of the spec for
> example that extended the IGD functionality).
> 
> 
> I understand that the layout within OpRegion  is defined by the spec
> and should be common.
> But I don't see any words (may be I missed something) about the layout
> of the outside world (e.g. what region is adjacent to OpRegion?).
> So my question is actually can we expect a constant layout with regard
> to OpRegion's neighbors?

Ok sorry, I did not understand the question fully. We may be able to sort
out what is in those NVS areas.

> 
> My impression from Ian's feedback is that the patch cannot be accepted
> before the concern being resolved.
> (Let alone the existing code in the tree has already open a hole
> (first 18 bytes in my example))
> And you mentioned that such info can be obtained from my host bios.
> I've dumped the ACPI table from my host system and had it disassembled
> by iasl.
> But I lack of the knowledge to interpret the content.
> Could you lend me a hand in case that's a trivial task for you?
> You can find the DSDT.dsl file attached in my previous mail (@2012-12-
> 23).

Sure I can take a look. Can you send me a dump of your e820 map on the
system in question (and an lspci dump while you are at it)? Also I think
you may have mentioned it but what base address is the ASLS register
reporting?

Thanks

> 
> If you don't have time to help, could you point me to a proper spec /
> documentation to start with?
> 
> Thanks,
> Timothy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel