Thanks, but actually I think the iomem integration is more broken than it
first appears. I'm not sure why the local iomem permissions are modified at
all. The remote permissions should be interrogated, and that should suffice
alone. But you certainly have the gist of a fix here -- AFAICS the code
as-is allows unprivileged domains to 'grant' each other access to arbitrary
pages of I/O memory, which isn't good. I've cc'ed Kieran who was the
originator of that code.
-- Keir
On 9/11/07 15:13, "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx> wrote:
> Hi,
>
> While developping a frontend, I noticed that if I gave a grant on mfn 0
> to a backend (which is bogus), that backend would happily be allowed to
> map it, and hence Oops...
>
> This is because mfn 0 is considered as iomem, and in that case
> gnttab_map_grant_ref only checks that the target domain is allowed to
> access it. The patch below makes it check that the source domain was
> allowed to access it (and then give the target access to it).
>
> Samuel
>
> Signed-Off-By: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
>
> diff -r 4bf62459d45a xen/common/grant_table.c
> --- a/xen/common/grant_table.c Wed Nov 07 11:29:38 2007 +0000
> +++ b/xen/common/grant_table.c Fri Nov 09 15:01:57 2007 +0000
> @@ -335,7 +335,8 @@ __gnttab_map_grant_ref(
> if ( iomem_page_test(frame, mfn_to_page(frame)) )
> {
> is_iomem = 1;
> - if ( iomem_permit_access(ld, frame, frame) )
> + if ( !iomem_access_permitted(rd, frame, frame)
> + || iomem_permit_access(ld, frame, frame) )
> {
> gdprintk(XENLOG_WARNING,
> "Could not permit access to grant frame "
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home