sHype changeset causes error in domU creation

sHype changeset causes error in domU creation

[George Washington Dunlap III]

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)

Re: sHype changeset causes error in domU creation

[Keir Fraser]

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.")
> ---

Re: sHype changeset causes error in domU creation

[Stefan Berger]

[-- Attachment #1.1: Type: text/plain, Size: 708 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1094 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: sHype changeset causes error in domU creation

[George Washington Dunlap III]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1185 bytes --]

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)

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2986 bytes --]

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/boot/vmlinuz-2.6.11-xenU"

# Optional ramdisk.
ramdisk = "/root/ttylinux-ram"

# The domain build function. Default is 'linux'.
builder='linux'

# Initial memory allocation (in megabytes) for the new domain.
memory = 64

# A name for your domain. All domains must have different names.
name = "xmr"

# Which CPU to start domain on? 
#cpu = -1   # leave to Xen to pick

# Number of Virtual CPUS to use, default is 1
#vcpus = 1

#----------------------------------------------------------------------------
# Define network interfaces.

# Number of network interfaces. Default is 1.
nics=0

# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'mac=aa:00:00:00:00:11, bridge=xen-br0' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

#disk = [ 'phy:hda1,hda1,w' ]

#----------------------------------------------------------------------------
# Set the kernel command line for the new domain.
# You only need to define the IP parameters and hostname if the domain's
# IP config doesn't, e.g. in ifcfg-eth0 or via DHCP.
# You can use 'extra' to set the runlevel and custom environment
# variables used by custom rc scripts (e.g. VMID=, usr= ).

# Set if you want dhcp to allocate the IP address.
#dhcp="dhcp"
# Set netmask.
#netmask=
# Set default gateway.
#gateway=
# Set the hostname.
#hostname= "vm%d" % vmid

# Set root device.
root = "/dev/ram0 ro"

# Root device for nfs.
#root = "/dev/nfs"
# The nfs server.
#nfs_server = '169.254.1.0'  
# Root directory on the nfs server.
#nfs_root   = '/full/path/to/root/directory'

# Sets runlevel 4.
extra = "4 ramdisk_size=16384"

#----------------------------------------------------------------------------
# Set according to whether you want the domain restarted when it exits.
# The default is 'onreboot', which restarts the domain when it shuts down
# with exit code reboot.
# Other values are 'always', and 'never'.

#restart = 'onreboot'

#============================================================================

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: sHype changeset causes error in domU creation

[Steven Hand]

>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.

Re: sHype changeset causes error in domU creation

[Reiner Sailer]

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.")
> > ---
> 

Re: sHype changeset causes error in domU creation

[Stefan Berger]

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',

Re: sHype changeset causes error in domU creation

[Steven Hand]

> >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. 

Re: sHype changeset causes error in domU creation

[Keir Fraser]

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

Re: sHype changeset causes error in domU creation

[George Washington Dunlap III]

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)

Re: sHype changeset causes error in domU creation

[Reiner Sailer]

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

Re: sHype changeset causes error in domU creation

[aq]

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