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: Thursday, January 10, 2013 5:27 AM
> To: Ross Philipson
> Cc: Ian Campbell; 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.
> 
> >> >> 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.
> >
> 
> If we need to sort out ourselves, I guess we need more samples from
> different vendors / bios versions.
> Do we need to dump them from a live system, or this can be easily
> extracted from the bios rom file?

I am not sure yet. I was hoping we could correlate those regions to
something concrete - e.g. in a spec. 

> 
> >>
> >> 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?
> 
> First of all, are you asking for the guest or the host? Host, I guess?
> I'm not sure how to dump the e820 map.
> Previously I used acpidump to get acpitables and use iasl to disassemble
> them.
> Are you talking about the same work flow?

Host. The easiest way to get it is if you can get serial output from Xen
which should report it early on. Or your kernel may report it; mine does
and I can get it via dmesg (traced as "Xen-provided memory map").

For PCI I just wanted the output from lspci (e.g. lspci -v and lspci -xxx).



> 
> Thanks,
> Timothy

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