Xen devel - Jun 2005 - sHype changeset causes error in domU creation

The changeset adding ssid variable to domain creation causes the following 
error when I try to create a domain:

---
Traceback (most recent call last):
   File "/usr/lib/python/xen/xend/server/SrvDomainDir.py", line 63, in
op_create
     dominfo = self.xd.domain_create(config)
   File "/usr/lib/python/xen/xend/XendDomain.py", line 276, in 
domain_create
     dominfo = XendDomainInfo.create(self.dbmap, config)
   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 159, in
create
     vm.construct(config)
   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 510, in 
construct
     self.init_domain()
   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 670, in 
init_domain
     id = self.image.initDomain(self.id, self.memory, self.ssidref, cpu, 
self.cpu_weight)
   File "/usr/lib/python/xen/xend/image.py", line 122, in initDomain
     dom = xc.domain_create(dom = dom or 0, ssidref = ssidref)
OverflowError: long int too large to convert to int
---

Changing the following line makes a temporary fix:

tools/python/xen/xm/create.py
--
  gopts.var(''ssidref'', val=''SSIDREF'',
-          fn=set_u32, default=0xfffffff,
            use="Security Identifier.")
++
gopts.var(''ssidref'', val=''SSIDREF'',
+          fn=set_u32, default=0xffff,
           use="Security Identifier.")
---

I''m using the following python version:

Python 2.4.1 (#1, May 19 2005, 16:02:59)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-24)] on linux2

Peace,
  -George

+-------------------+----------------------------------------
| dunlapg@umich.edu | http://www-personal.umich.edu/~dunlapg 
+-------------------+----------------------------------------
|  Who could move a mountain, who could love their enemy?
|  Who could rejoice in pain, and turn the other cheek?
|	- Rich Mullins, "Surely God is With Us"
+------------------------------------------------------------
| Outlaw Junk Email! Support HR 1748 (www.cauce.org)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Having ssidref as a required parameter to domain_create is an ugly 
nuisance for the 99.9% of people who don''t care a jot about it. I think
a separate one-time-only hypercall to set the ssidref on a newly 
created domain would be neater? Or at least, surely the sane default 
value for an integer ssidref is zero, not fffffffff?

  -- Keir

On 22 Jun 2005, at 17:13, George Washington Dunlap III wrote:
> Changing the following line makes a temporary fix:
>
> tools/python/xen/xm/create.py
> --
>  gopts.var(''ssidref'', val=''SSIDREF'',
> -          fn=set_u32, default=0xfffffff,
>            use="Security Identifier.")
> ++
> gopts.var(''ssidref'', val=''SSIDREF'',
> +          fn=set_u32, default=0xffff,
>           use="Security Identifier.")
> ---

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 06/22/2005 11:13:09 AM:
> 
> Changing the following line makes a temporary fix:
> 
> tools/python/xen/xm/create.py
> --
>   gopts.var(''ssidref'', val=''SSIDREF'',
> -          fn=set_u32, default=0xfffffff,
>             use="Security Identifier.")
> ++
> gopts.var(''ssidref'', val=''SSIDREF'',
> +          fn=set_u32, default=0xffff,
>            use="Security Identifier.")
> ---
> 
> I''m using the following python version:
> 
> Python 2.4.1 (#1, May 19 2005, 16:02:59)
> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-24)] on linux2
I am using version 2.3.4 and do not encounter this problem. Did you put 
any ssidref line into the VM configuration file?

   Stefan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 22 Jun 2005, Stefan Berger wrote:
>> Changing the following line makes a temporary fix:
>>
>> tools/python/xen/xm/create.py
>> --
>>   gopts.var(''ssidref'',
val=''SSIDREF'',
>> -          fn=set_u32, default=0xfffffff,
>>             use="Security Identifier.")
>> ++
>> gopts.var(''ssidref'', val=''SSIDREF'',
>> +          fn=set_u32, default=0xffff,
>>            use="Security Identifier.")
[snip]
> I am using version 2.3.4 and do not encounter this problem. Did you put
> any ssidref line into the VM configuration file?
No -- I just used the config file that worked before the update. :-) 
I''ve attached it for reference.  Consider me as testing backwards 
compatibility and/or useful failure messages. :-)

  -George

+-------------------+----------------------------------------
| dunlapg@umich.edu | http://www-personal.umich.edu/~dunlapg 
+-------------------+----------------------------------------
|  Who could move a mountain, who could love their enemy?
|  Who could rejoice in pain, and turn the other cheek?
|	- Rich Mullins, "Surely God is With Us"
+------------------------------------------------------------
| Outlaw Junk Email! Support HR 1748 (www.cauce.org)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>The changeset adding ssid variable to domain creation causes the following 
>error when I try to create a domain:
>
>---
>Traceback (most recent call last):
>   File "/usr/lib/python/xen/xend/server/SrvDomainDir.py", line
63, in
>op_create
>     dominfo = self.xd.domain_create(config)
>   File "/usr/lib/python/xen/xend/XendDomain.py", line 276, in 
>domain_create
>     dominfo = XendDomainInfo.create(self.dbmap, config)
>   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 159, in
create
>     vm.construct(config)
>   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 510, in
>construct
>     self.init_domain()
>   File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 670, in
>init_domain
>     id = self.image.initDomain(self.id, self.memory, self.ssidref, cpu, 
>self.cpu_weight)
>   File "/usr/lib/python/xen/xend/image.py", line 122, in
initDomain
>     dom = xc.domain_create(dom = dom or 0, ssidref = ssidref)
>OverflowError: long int too large to convert to int
Bizarre - this seems to be a python 2.4 only property... and is also 
odd in that python is trying to convert ssidref to an int (rather than
an unsigned one). Possibly a side effect of the unified int/long stuff, 
possibly a minor change in the native method interface, possibly a 
change to u32.py... 
>Changing the following line makes a temporary fix:
Well not really a fix so much as a "make the exception go away" :-) 
I''ll take a look tomorrow at the best way to fix this - may be that
Keir''s suggestion of using 0 as the ''null'' ssidref is
correct, although
zero currently has another meaning... 

cheers,

S.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 06/22/2005 01:09:09 PM:
> 
> Having ssidref as a required parameter to domain_create is an ugly 
> nuisance for the 99.9% of people who don''t care a jot about it. 
You don''t have to set up an ssid if you don''t run a policy.
Using
the NULL policy, shype should not introduce any change in system
behavior.

The problem at hand is that the defined default id is the largest u32 
number and with the (new?) Python version this seems not to work the 
way it does with older ones.
> I think 
> a separate one-time-only hypercall to set the ssidref on a newly 
> created domain would be neater? 
I consider this not an option because the ssidref is used for determining
about domain creation.
>Or at least, surely the sane default 
> value for an integer ssidref is zero, not fffffffff?
This is a very good idea. We must either fix the problem with setting
an unsigned number 0xffffffff as default or we change the default
number to one that Python can work with.
>   -- Keir
> 
> On 22 Jun 2005, at 17:13, George Washington Dunlap III wrote:
> 
> > Changing the following line makes a temporary fix:
> >
> > tools/python/xen/xm/create.py
> > --
> >  gopts.var(''ssidref'',
val=''SSIDREF'',
> > -          fn=set_u32, default=0xfffffff,
> >            use="Security Identifier.")
> > ++
> > gopts.var(''ssidref'',
val=''SSIDREF'',
> > +          fn=set_u32, default=0xffff,
> >           use="Security Identifier.")
> > ---
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefan Berger
T. J. Watson Research Center, 
Hawthorne, NY, USA
tel#: +1 914 784 7767 , 
fax#: +1 914 784 6225
e-mail: stefanb@us.ibm.com

xen-devel-bounces@lists.xensource.com wrote on 06/22/2005 07:35:59 PM:
> 
> >The changeset adding ssid variable to domain creation causes the 
following 
> >error when I try to create a domain:
> >
[...]
> >   File "/usr/lib/python/xen/xend/image.py", line 122, in
initDomain
> >     dom = xc.domain_create(dom = dom or 0, ssidref = ssidref)
> >OverflowError: long int too large to convert to int
> 
> Bizarre - this seems to be a python 2.4 only property... and is also 
> odd in that python is trying to convert ssidref to an int (rather than
> an unsigned one). Possibly a side effect of the unified int/long stuff, 
> possibly a minor change in the native method interface, possibly a 
> change to u32.py... 
> 
This is a problem that comes with an FC 4 install and the newer python 
that comes along with it.
Below a patch that solves the problem. ( default=~0 would also work )

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>

diff -uprN ./xeno-unstable.bk.orig/tools/python/xen/xm/create.py 
./xeno-unstable.bk/tools/python/xen/xm/create.py
--- ./xeno-unstable.bk.orig/tools/python/xen/xm/create.py 2005-06-22 
22:38:51.000000000 -0400
+++ ./xeno-unstable.bk/tools/python/xen/xm/create.py 2005-06-22 
22:43:57.000000000 -0400
@@ -121,7 +121,7 @@ gopts.var(''memory'',
val=''MEMORY'',
           use="Domain memory in MB.")
 
 gopts.var(''ssidref'', val=''SSIDREF'',
-          fn=set_u32, default=0xffffffff,
+          fn=set_u32, default=-1,
           use="Security Identifier.")
 
 gopts.var(''maxmem'', val=''MEMORY'',



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> >Changing the following line makes a temporary fix:
> 
> Well not really a fix so much as a "make the exception go away"
:-)
> I''ll take a look tomorrow at the best way to fix this - may be
that
> Keir''s suggestion of using 0 as the ''null''
ssidref is correct, although
> zero currently has another meaning... 
I''ve checked in a [potential] fix for now, but since I don''t
have a
python 2.4 install handy it''d be great if you could test it. 

Longer term (next week?) we should probably think more about whether
we can move to a ''0'' default (or at least
''null'') ssidref.



cheers,

S. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23 Jun 2005, at 04:01, Stefan Berger wrote:
> This is a problem that comes with an FC 4 install and the newer python
> that comes along with it.
> Below a patch that solves the problem. ( default=~0 would also work )
>
> Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Steve applied this patch, but I''d strongly argue for 0 as the default 
ssid value. I don''t know if this this is a hard change to make?

As an aside, I also don''t like the name of the policy hypercall and 
policy control tools. Can we call them ''acm_policy'' or 
''security_policy'' or something like that? Calling them
''policy'' with no
further qualification is too vague.

  Cheers,
  Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Replacing it with -1 solves the problem.  Thanks!

  -George

On Thu, 23 Jun 2005, Keir Fraser wrote:
>
> On 23 Jun 2005, at 04:01, Stefan Berger wrote:
>
>> This is a problem that comes with an FC 4 install and the newer python
>> that comes along with it.
>> Below a patch that solves the problem. ( default=~0 would also work )
>> 
>> Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
>
> Steve applied this patch, but I''d strongly argue for 0 as the
default ssid
> value. I don''t know if this this is a hard change to make?
>
> As an aside, I also don''t like the name of the policy hypercall
and policy
> control tools. Can we call them ''acm_policy'' or
''security_policy'' or
> something like that? Calling them ''policy'' with no
further qualification is
> too vague.
>
> Cheers,
> Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
+-------------------+----------------------------------------
| dunlapg@umich.edu | http://www-personal.umich.edu/~dunlapg 
+-------------------+----------------------------------------
|  Who could move a mountain, who could love their enemy?
|  Who could rejoice in pain, and turn the other cheek?
|	- Rich Mullins, "Surely God is With Us"
+------------------------------------------------------------
| Outlaw Junk Email! Support HR 1748 (www.cauce.org)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 06/23/2005 05:48:12 AM:
> 
> On 23 Jun 2005, at 04:01, Stefan Berger wrote:
> 
> > This is a problem that comes with an FC 4 install and the newer python
> > that comes along with it.
> > Below a patch that solves the problem. ( default=~0 would also work )
> >
> > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> 
> Steve applied this patch, but I''d strongly argue for 0 as the
default
> ssid value. I don''t know if this this is a hard change to make?
Hi Keir, we already started to change the default ssid (to 0). The change 
is not much work but will need testing. We will have a patch in a few 
days.
> As an aside, I also don''t like the name of the policy hypercall
and
> policy control tools. Can we call them ''acm_policy'' or 
> ''security_policy'' or something like that? Calling them
''policy'' with no
> further qualification is too vague.
This is a good suggestion as well. We are going to make the name change
to security_policy. acm_policy is a bit too restrictive since the security
architecture will generally involve more than just the current access 
control 
module.
>   Cheers,
>   Keir
> 
Thanks
Reiner

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/24/05, Reiner Sailer <sailer@us.ibm.com>
wrote:
> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 06/23/2005 05:48:12
AM:
> 
> >
> > On 23 Jun 2005, at 04:01, Stefan Berger wrote:
> >
> > > This is a problem that comes with an FC 4 install and the newer
python
> > > that comes along with it.
> > > Below a patch that solves the problem. ( default=~0 would also
work )
> > >
> > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> >
> > Steve applied this patch, but I''d strongly argue for 0 as the
default
> > ssid value. I don''t know if this this is a hard change to
make?
> 
> Hi Keir, we already started to change the default ssid (to 0). The change
> is not much work but will need testing. We will have a patch in a few
> days.
> 
> > As an aside, I also don''t like the name of the policy
hypercall and
> > policy control tools. Can we call them ''acm_policy''
or
> > ''security_policy'' or something like that? Calling
them ''policy'' with no
> > further qualification is too vague.
> 
> This is a good suggestion as well. We are going to make the name change
> to security_policy. acm_policy is a bit too restrictive since the security
> architecture will generally involve more than just the current access
> control
> module.
BTW, how about changing the name of "policy_tool" (in tool/policy/)? i
guess it has the same problem, doesnt it?

regards,
aq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel