linux-kernel - Re: Regressions in v3.3-rc1 introduced by "xen/granttable: Grant tables V2 implementation"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jan 2012 09:55:33 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"annie.li@...cle.com" <annie.li@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: Regressions in v3.3-rc1 introduced by "xen/granttable: Grant
 tables V2 implementation"

On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> 
> .. snip..
> > 
> > and with this little patch I can get it to work:
> 
> I get the domU to boot but the network stops being responsive.
> I see this in the Dom0:

Your original patch would set the version to two in the hypervisor and
then ignore that and continue to use v1 so that isn't surprising.

> (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> 
> Replacing the patch with:
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 1cd94da..b4d4eac 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	gsv.version = 2;
> +	if (xen_hvm_domain())
> +		gsv.version = 1;
> +	else
> +		gsv.version = 2;
>  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> -	if (rc == 0) {
> +	if (rc == 0 && gsv.version == 2) {
>  		grant_table_version = 2;
>  		gnttab_interface = &gnttab_v2_ops;
>  	} else if (grant_table_version == 2) {
> 
> Gets me back to how it worked in Linux v3.2.
> 
> But that is just a band-aid fix...

The real bug is presumably either that the Linux v2 code is buggy for
use in an HVM guest or that Xen's support for v2 in HVM guests is either
buggy or explicitly disabled (in which case set_version should fail for
version=2).

Is the set_version with version=1 succeeding or failing? Likewise for
the version=2 call?

The original error was an "unable to handle kernel NULL pointer
dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
plausible candidates for such an error are the array access into to
either the gnttab_shared or grstatus arrays. Do you know which one the
IP corresponds to?

On HVM for gnttab_shared we make an add_to_physmap call with
XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
do something similar for the status array though and I don't see a
XENMAPSPACE_* specifically for that case either in the hypervisor
either.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/