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

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

On Thu, Dec 20, 2012 at 10:19 PM, Keir Fraser <keir@xxxxxxx> wrote:
> On 20/12/2012 13:31, "G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> If concern is about security, the same argument should apply to the
>> first page (the portion before the page offset).
>> The problem is that I have no idea what is around the mapped page. Not
>> sure who has the knowledge.
>
> Well we can't do better than mapping some whole number of pages, really.
> Unless we trap to qemu on every access. I don't think we'd go there unless
> there really were a known security issue. But mapping only the exact number
> of pages we definitely need is a good principle.
>
>> What's the standard flow to handle such map with offset?
>> I expect this to be a common case, since the ioremap function in linux
>> kernel accept this.
>
> map_size = ((host_opregion & 0xfff) + 8096 + 0xfff) >> 12
>
Keir, I believe this expression should give the same result.
First of all, 8096 should be 8192 :-), and this part should result in
an constant number 2 after right shift.
The remaining part is ((host_opregion & 0xfff) + 0xfff) >> 12
As long as the first sub-expression is non zero, the result of the add
should range from [0x1000, 0x1ffe].
And this will yield a result '1' after the right shift.
So as long as there is known security risk (which I'm not sure about),
the patch should be fine.

> Possibly with suitable macros used instead of magic numbers (e.g., XC_PAGE_*
> and a macro for the opregion size).

I guess there is no predefined macro for OpRegion size. And I guess I
need to define it twice for both code?

>  -- Keir
>
>

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