Skip to contentSkip to conversation

fix broken ACM

PATCH In review aq 3 participants 18 messages Jun 22, 2005 – Jun 23, 2005

lore
Share & tools
lore

aq

author
#0 lore raw

PATCH 1/1 fix broken ACM

The latest change to ACM makes it fail to compile. This patch fixes the problem.

Signed-off-by Nguyen Anh Quynh <[email protected]>
$ diffstat acm.patch 
 acm/acm_core.c          |   61 ---------------------
 include/acm/acm_hooks.h |  135 ++++++++++++++++++++++++++++++++++--------------
 2 files changed, 96 insertions(+), 100 deletions(-)

===== xen/acm/acm_core.c 1.1 vs edited =====

xen/acm/acm_core.c +0 -61
@@ -69,67 +69,6 @@
     }
 }
 
-/* initialize global security policy for Xen; policy write-locked already */
-static void
-acm_init_binary_policy(void *primary, void *secondary)
-{
-	acm_bin_pol.primary_policy_code = 0;
-	acm_bin_pol.secondary_policy_code = 0;
-	acm_bin_pol.primary_binary_policy = primary;
-	acm_bin_pol.secondary_binary_policy = secondary;
-}
-
-int
-acm_init(void)
-{
-	int ret = -EINVAL;
-
-	acm_set_endian();
-	write_lock(&acm_bin_pol_rwlock);
-
-	if (ACM_USE_SECURITY_POLICY == ACM_CHINESE_WALL_POLICY) {
-		acm_init_binary_policy(NULL, NULL);
-		acm_init_chwall_policy();
-		acm_bin_pol.primary_policy_code = ACM_CHINESE_WALL_POLICY;
-		acm_primary_ops = &acm_chinesewall_ops;
-		acm_bin_pol.secondary_policy_code = ACM_NULL_POLICY;
-		acm_secondary_ops = &acm_null_ops;
-		ret = ACM_OK;
-	} else if (ACM_USE_SECURITY_POLICY == ACM_SIMPLE_TYPE_ENFORCEMENT_POLICY) {
-		acm_init_binary_policy(NULL, NULL);
-		acm_init_ste_policy();
-		acm_bin_pol.primary_policy_code = ACM_SIMPLE_TYPE_ENFORCEMENT_POLICY;
-		acm_primary_ops = &acm_simple_type_enforcement_ops;
-		acm_bin_pol.secondary_policy_code = ACM_NULL_POLICY;
-		acm_secondary_ops = &acm_null_ops;
-		ret = ACM_OK;
-	} else if (ACM_USE_SECURITY_POLICY == ACM_CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT_POLICY) {
-		acm_init_binary_policy(NULL, NULL);
-		acm_init_chwall_policy();
-		acm_init_ste_policy();
-		acm_bin_pol.primary_policy_code = ACM_CHINESE_WALL_POLICY;
-		acm_primary_ops = &acm_chinesewall_ops;
-		acm_bin_pol.secondary_policy_code = ACM_SIMPLE_TYPE_ENFORCEMENT_POLICY;
-		acm_secondary_ops = &acm_simple_type_enforcement_ops;
-		ret = ACM_OK;
-	} else if (ACM_USE_SECURITY_POLICY == ACM_NULL_POLICY) {
-		acm_init_binary_policy(NULL, NULL);
-		acm_bin_pol.primary_policy_code = ACM_NULL_POLICY;
-		acm_primary_ops = &acm_null_ops;
-		acm_bin_pol.secondary_policy_code = ACM_NULL_POLICY;
-		acm_secondary_ops = &acm_null_ops;
-		ret = ACM_OK;
-	}
-	write_unlock(&acm_bin_pol_rwlock);
-
-	if (ret != ACM_OK)
-		return -EINVAL;		
-	printk("%s: Enforcing Primary %s, Secondary %s.\n", __func__, 
-	       ACM_POLICY_NAME(acm_bin_pol.primary_policy_code), ACM_POLICY_NAME(acm_bin_pol.secondary_policy_code));
-	return ACM_OK;
-}
-
-
 int
 acm_init_domain_ssid(domid_t id, ssidref_t ssidref)
 {

===== xen/include/acm/acm_hooks.h 1.2 vs edited =====

xen/include/acm/acm_hooks.h +96 -39

159 lines not on this page · raw message

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

author
#2 lore raw
Quoted 9 lines · Keir Fraser
Quoted 4 lines · aq

The latest change to ACM makes it fail to compile. This patch fixes the problem.

Signed-off-by Nguyen Anh Quynh <[email protected]>

It builds fine for me.

are you sure? on my system, without the patch acm_init() would be defined twice.

also, some structrures and global variables are hidden in the #else (of #if (ACM_USE_SECURITY_POLICY == ACM_NULL_POLICY) )

how did you compile acm?

regards,
aq

#3 lore raw
Quoted 8 lines · aq

are you sure? on my system, without the patch acm_init() would be defined twice.

also, some structrures and global variables are hidden in the #else (of #if (ACM_USE_SECURITY_POLICY == ACM_NULL_POLICY) )

how did you compile acm?

The whole point is not to bother, if the statically chosen security policy is null. We only build in acm if ACM_USE_SECURITY_POLICY is overridden -- this I may have broken since there was no sensible way provided by the original patch for users to override the default null security policy.

-- Keir

author
#4 lore raw
Quoted 6 lines · Keir Fraser
Quoted 3 lines · aq

are you sure? on my system, without the patch acm_init() would be defined twice.

Quoted 8 lines
Quoted 5 lines

also, some structrures and global variables are hidden in the #else (of #if (ACM_USE_SECURITY_POLICY == ACM_NULL_POLICY) )

how did you compile acm?

The whole point is not to bother, if the statically chosen security policy is null.

i see, but the problem occurs if we want to compile it. the reason is because you grouped null ops together, but you accidentally hide some structures and variables. also we must enclose the declare of acm_init() in #if (ACM_USE_SECURITY_POLICY = ACM_NULL_POLICY). please see my second patch.

regards,
aq

#5 lore raw
Quoted 5 lines · aq

i see, but the problem occurs if we want to compile it. the reason is because you grouped null ops together, but you accidentally hide some structures and variables. also we must enclose the declare of acm_init() in #if (ACM_USE_SECURITY_POLICY = ACM_NULL_POLICY). please see my second patch.

If we build non-NULL security policy then the struct definitions and so on are compiled in, because they are in the else clause of the acm header file.

-- Keir

author
#6 lore raw
Quoted 9 lines · Keir Fraser
Quoted 5 lines · aq

i see, but the problem occurs if we want to compile it. the reason is because you grouped null ops together, but you accidentally hide some structures and variables. also we must enclose the declare of acm_init() in #if (ACM_USE_SECURITY_POLICY = ACM_NULL_POLICY). please see my second patch.

Quoted 3 lines

If we build non-NULL security policy then the struct definitions and so on are compiled in, because they are in the else clause of the acm header file.

yes, that is true. but the default policy is NULL, and we get the problem compiling the code at the moment. my patch does nothing, just tries to fix the compiling problem (in default state).

regards,
aq

author
#7 lore raw
In reply to Keir Fraser
Quoted 9 lines · Keir Fraser
Quoted 4 lines · aq

The latest change to ACM makes it fail to compile. This patch fixes the problem.

Signed-off-by Nguyen Anh Quynh <[email protected]>

It builds fine for me.

here is part of output error i got when i compile ACM without the patch above ([email protected])

..
make -C acm
make[1]: Entering directory `/home/bun/projects/xen/xeno.0620/xen/acm' gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/home/bun/projects/xen/xeno.0620/xen/include -I/home/bun/projects/xen/xeno.0620/xen/include/asm-x86/mach-generic -I/home/bun/projects/xen/xeno.0620/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c acm_core.c -o acm_core.o
acm_core.c:84: error: redefinition of `acm_init' /home/bun/projects/xen/xeno.0620/xen/include/acm/acm_hooks.h:48:
error: `acm_init' previously defined here
acm_core.c: In function `acm_init_domain_ssid':
acm_core.c:160: error: dereferencing pointer to incomplete type acm_core.c:161: error: dereferencing pointer to incomplete type acm_core.c:165: error: dereferencing pointer to incomplete type acm_core.c:166: error: dereferencing pointer to incomplete type acm_core.c: In function `acm_free_domain_ssid':
acm_core.c:196: error: dereferencing pointer to incomplete type acm_core.c:197: error: dereferencing pointer to incomplete type acm_core.c:199: error: dereferencing pointer to incomplete type acm_core.c:200: error: dereferencing pointer to incomplete type make[1]: *** [acm_core.o] Error 1
make[1]: Leaving directory `/home/bun/projects/xen/xeno.0620/xen/acm'
make: *** [/home/bun/projects/xen/xeno.0620/xen/xen] Error 2

regards,
aq

#8 lore raw
In reply to aq

[email protected] wrote on 06/22/2005 01:40:16 PM:

Quoted 1 line

The latest change to ACM makes it fail to compile. This patch fixes the

problem.

Quoted 6 lines
Signed-off-by Nguyen Anh Quynh <[email protected]>
$ diffstat acm.patch 
 acm/acm_core.c          |   61 ---------------------
 include/acm/acm_hooks.h |  135

++++++++++++++++++++++++++++++++++--------------

Quoted 2 lines
 2 files changed, 96 insertions(+), 100 deletions(-)

[attachment "acm.patch" deleted by Stefan Berger/Watson/IBM]

This patch seems to work for gcc 4.0.0 (FC4), but the resulting source does not compile with gcc 3.4.3 (FC3). I will try to find a common solution. I think the problem is related to gcc 3.4.3 having a limit on inline functions.

Stefan

author
#9 lore raw
Quoted 10 lines · Stefan Berger

[email protected] wrote on 06/22/2005 01:40:16 PM:

Quoted 1 line

The latest change to ACM makes it fail to compile. This patch fixes the

problem.

Quoted 6 lines
Signed-off-by Nguyen Anh Quynh <[email protected]>
$ diffstat acm.patch
 acm/acm_core.c          |   61 ---------------------
 include/acm/acm_hooks.h |  135
Quoted 8 lines

++++++++++++++++++++++++++++++++++--------------

Quoted 2 lines
 2 files changed, 96 insertions(+), 100 deletions(-)

[attachment "acm.patch" deleted by Stefan Berger/Watson/IBM]

This patch seems to work for gcc 4.0.0 (FC4), but the resulting source does not compile with gcc 3.4.3 (FC3). I will try to find a common solution. I think the problem is related to gcc 3.4.3 having a limit on inline functions.

it builds fine for me on gcc 3.3.5

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)

regards,
aq

#10 lore raw

aq <[email protected]> wrote on 06/22/2005 11:56:07 PM:

Quoted 4 lines · Stefan Berger
Quoted 3 lines

[email protected] wrote on 06/22/2005 01:40:16 PM:

Quoted 1 line

The latest change to ACM makes it fail to compile. This patch fixes

the

Quoted 7 lines
Quoted 7 lines

problem.

Quoted 6 lines
Signed-off-by Nguyen Anh Quynh <[email protected]>
$ diffstat acm.patch
 acm/acm_core.c          |   61 ---------------------
 include/acm/acm_hooks.h |  135
Quoted 7 lines
Quoted 7 lines

++++++++++++++++++++++++++++++++++--------------

Quoted 2 lines
 2 files changed, 96 insertions(+), 100 deletions(-)

[attachment "acm.patch" deleted by Stefan Berger/Watson/IBM]

This patch seems to work for gcc 4.0.0 (FC4), but the resulting source does not compile with gcc 3.4.3 (FC3). I will try to find a common solution. I think the problem is related to gcc 3.4.3 having a limit

on

Quoted 4 lines
Quoted 1 line

inline functions.

it builds fine for me on gcc 3.3.5

Quoted 12 lines
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)

It seems to be missing a couple of prototypes.

In file included from dom0_ops.c:22:
/xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h: In function `acm_init':
/xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:359: warning: implicit declaration of function acm_set_endian' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:364: warning: implicit declaration of function acm_init_chwall_policy' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error:
`acm_chinesewall_ops' undeclared (first use in this function) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error: (Each undeclared identifier is reported only once /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error: for each function it appears in.) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:368: error:
acm_null_ops' undeclared (first use in this function) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:372: warning: implicit declaration of function acm_init_ste_policy' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:374: error:
`acm_simple_type_enforcement_ops' undeclared (first use in this function) make[2]: *** [dom0_ops.o] Error 1
make[2]: Leaving directory `/xen/xeno-unstable.bk/xen/common' make[1]: *** [/xen/xeno-unstable.bk/xen/xen] Error 2
make[1]: Leaving directory `/xen/xeno-unstable.bk/xen'
make: *** [xen] Error 2

Once those are fixed the following happens:

ld   -m elf_i386  -T x86_32/xen.lds -N \
    boot/x86_32.o /xen/xeno-unstable.bk/xen/common/common.o

/xen/xeno-unstable.bk/xen/drivers/char/driver.o /xen/xeno-unstable.bk/xen/drivers/acpi/driver.o /xen/xeno-unstable.bk/xen/arch/x86/arch.o -o /xen/xeno-unstable.bk/xen/xen-syms /xen/xeno-unstable.bk/xen/common/common.o(.text+0x121a): In function `do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1246): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x126b): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1288): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12b0): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12c0): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12d7): In function do_dom0_op':
: undefined reference to acm_free_domain_ssid' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x134e): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1376): In function do_dom0_op':
: undefined reference to `acm_init_domain_ssid'
[...]

gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20050104 (Red Hat 3.4.3-13)

What is the compiler problem that you fixed with your patch?

Stefan

author
#11 lore raw
Quoted 94 lines · Stefan Berger

aq <[email protected]> wrote on 06/22/2005 11:56:07 PM:

Quoted 4 lines · Stefan Berger
Quoted 3 lines

[email protected] wrote on 06/22/2005 01:40:16 PM:

Quoted 1 line

The latest change to ACM makes it fail to compile. This patch fixes

the

Quoted 7 lines
Quoted 7 lines

problem.

Quoted 6 lines
Signed-off-by Nguyen Anh Quynh <[email protected]>
$ diffstat acm.patch
 acm/acm_core.c          |   61 ---------------------
 include/acm/acm_hooks.h |  135
Quoted 7 lines
Quoted 7 lines

++++++++++++++++++++++++++++++++++--------------

Quoted 2 lines
 2 files changed, 96 insertions(+), 100 deletions(-)

[attachment "acm.patch" deleted by Stefan Berger/Watson/IBM]

This patch seems to work for gcc 4.0.0 (FC4), but the resulting source does not compile with gcc 3.4.3 (FC3). I will try to find a common solution. I think the problem is related to gcc 3.4.3 having a limit

on

Quoted 4 lines
Quoted 1 line

inline functions.

it builds fine for me on gcc 3.3.5

Quoted 12 lines
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)

It seems to be missing a couple of prototypes.

In file included from dom0_ops.c:22:
/xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h: In function `acm_init':
/xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:359: warning: implicit declaration of function acm_set_endian' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:364: warning: implicit declaration of function acm_init_chwall_policy' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error:
`acm_chinesewall_ops' undeclared (first use in this function) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error: (Each undeclared identifier is reported only once /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:366: error: for each function it appears in.) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:368: error:
acm_null_ops' undeclared (first use in this function) /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:372: warning: implicit declaration of function acm_init_ste_policy' /xen/xeno-unstable.bk/xen/include/acm/acm_hooks.h:374: error:
`acm_simple_type_enforcement_ops' undeclared (first use in this function) make[2]: *** [dom0_ops.o] Error 1
make[2]: Leaving directory `/xen/xeno-unstable.bk/xen/common' make[1]: *** [/xen/xeno-unstable.bk/xen/xen] Error 2
make[1]: Leaving directory `/xen/xeno-unstable.bk/xen'
make: *** [xen] Error 2

Once those are fixed the following happens:

ld   -m elf_i386  -T x86_32/xen.lds -N \
    boot/x86_32.o /xen/xeno-unstable.bk/xen/common/common.o

/xen/xeno-unstable.bk/xen/drivers/char/driver.o /xen/xeno-unstable.bk/xen/drivers/acpi/driver.o /xen/xeno-unstable.bk/xen/arch/x86/arch.o -o /xen/xeno-unstable.bk/xen/xen-syms /xen/xeno-unstable.bk/xen/common/common.o(.text+0x121a): In function `do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1246): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x126b): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1288): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12b0): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12c0): In function do_dom0_op':
: undefined reference to acm_secondary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x12d7): In function do_dom0_op':

Quoted 9 lines

: undefined reference to acm_free_domain_ssid' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x134e): In function do_dom0_op':
: undefined reference to acm_primary_ops' /xen/xeno-unstable.bk/xen/common/common.o(.text+0x1376): In function do_dom0_op':
: undefined reference to `acm_init_domain_ssid'
[...]

ok, i see the point. the problem is because i moved some codes (acm_init() and acm_init_binary_policy()) to acm_hooks.h. now it seems better to move them back. but it is weird that i got no problem with gcc 3.3.5

could you please try again with the new patch below?

Signed-off-by Nguyen Anh Quynh <[email protected]>
# diffstat acm3.patch 
 acm/acm_core.c          |    3 +
 include/acm/acm_hooks.h |   76 ++++++++++++++++++++++++------------------------
 2 files changed, 41 insertions(+), 38 deletions(-)

===== xen/acm/acm_core.c 1.1 vs edited =====

xen/acm/acm_core.c +3 -0
@@ -79,6 +79,8 @@
 	acm_bin_pol.secondary_binary_policy = secondary;
 }
 
+#if (ACM_USE_SECURITY_POLICY != ACM_NULL_POLICY)
+
 int
 acm_init(void)
 {

@@ -129,6 +131,7 @@
 	return ACM_OK;
 }
 
+#endif
 
 int
 acm_init_domain_ssid(domid_t id, ssidref_t ssidref)

===== xen/include/acm/acm_hooks.h 1.2 vs edited =====

xen/include/acm/acm_hooks.h +38 -38

94 lines not on this page · raw message

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#12 lore raw

[email protected] wrote on 06/23/2005 03:56:52 AM:

Quoted 5 lines · Stefan Berger
Quoted 4 lines

aq <[email protected]> wrote on 06/22/2005 11:56:07 PM:

Quoted 2 lines · Stefan Berger
Quoted 1 line

[email protected] wrote on 06/22/2005 01:40:16

PM:

Quoted 8 lines
Quoted 1 line

ok, i see the point. the problem is because i moved some codes (acm_init() and acm_init_binary_policy()) to acm_hooks.h. now it seems better to move them back. but it is weird that i got no problem with gcc 3.3.5

could you please try again with the new patch below?

I tried it with your attached patch. There was an unused function when trying out the NULL policy. The attached patch on top of yours and things compile fine.

Signed-off-by Stefan Berger <[email protected]>
xen/acm/acm_core.c +2 -1
diff -uprN xeno-unstable.bk.orig/xen/acm/acm_core.c xeno-unstable.bk/xen/acm/acm_core.c
@@ -69,6 +69,8 @@ void acm_set_endian(void)
     }
 }
 
+#if (ACM_USE_SECURITY_POLICY != ACM_NULL_POLICY)
+
 /* initialize global security policy for Xen; policy write-locked already */
 static void
 acm_init_binary_policy(void *primary, void *secondary)

@@ -79,7 +81,6 @@ acm_init_binary_policy(void *primary, vo
 	acm_bin_pol.secondary_binary_policy = secondary;
 }
 
-#if (ACM_USE_SECURITY_POLICY != ACM_NULL_POLICY)
 
 int
 acm_init(void)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#13 lore raw
Quoted 10 lines · Stefan Berger
Quoted 6 lines

ok, i see the point. the problem is because i moved some codes (acm_init() and acm_init_binary_policy()) to acm_hooks.h. now it seems better to move them back. but it is weird that i got no problem with gcc 3.3.5

could you please try again with the new patch below?

I tried it with your attached patch. There was an unused function when trying out the NULL policy. The attached patch on top of yours and things compile fine.

I'm still confused what these patches are aiming to fix. If we are building 'NULL' security policy then all the hooks should compile away to nothing and acm core files do not get built. So why do they need patching with ifdef's conditional on whether or not the policy is 'NULL'?

Currently, if you re-enable building of acm/ directory in the Xen root Makefile, yet the ACM_USE_SECURITY_POLICY is NULL_POLICY, the build will certainly fail. But I don;t see why we would want to support that. :-)

-- Keir

author
#14 lore raw
Quoted 21 lines · Keir Fraser
Quoted 11 lines · Stefan Berger
Quoted 6 lines

ok, i see the point. the problem is because i moved some codes (acm_init() and acm_init_binary_policy()) to acm_hooks.h. now it seems better to move them back. but it is weird that i got no problem with gcc 3.3.5

could you please try again with the new patch below?

I tried it with your attached patch. There was an unused function when trying out the NULL policy. The attached patch on top of yours and things
compile fine.

I'm still confused what these patches are aiming to fix. If we are building 'NULL' security policy then all the hooks should compile away to nothing and acm core files do not get built. So why do they need patching with ifdef's conditional on whether or not the policy is 'NULL'?

Quoted 4 lines

Currently, if you re-enable building of acm/ directory in the Xen root Makefile, yet the ACM_USE_SECURITY_POLICY is NULL_POLICY, the build will certainly fail. But I don;t see why we would want to support that. :-)

Keir, certainly i understand your point. but this patch doesnt harm, anyway ;-)

one annoying problem at the moment is that if we want to compile ACM in, we should modify the value of ACM_USE_SECURITY_POLICY, since the current default value is ACM_NULL_POLICY( which is meaningless as Keir pointed out )

any clean way to overcome this problem?

regards,
aq

#15 lore raw
Quoted 1 line · aq

Keir, certainly i understand your point. but this patch doesnt harm, anyway ;-)

We need to understand why a patch is useful before we apply it.

Quoted 6 lines

one annoying problem at the moment is that if we want to compile ACM in, we should modify the value of ACM_USE_SECURITY_POLICY, since the current default value is ACM_NULL_POLICY( which is meaningless as Keir pointed out )

any clean way to overcome this problem?

The way I skip building acm directory in the root Makefile is quite gross, and won't actually detect if you edit ACM_USE_SECURITY_POLICY. Probably need to think about ways of cleanly expressing a new build config option for security policies etc. Then Makefile decision can hook off of that.

-- Keir

author
#16 lore raw
Quoted 13 lines · Keir Fraser
Quoted 2 lines · aq

Keir, certainly i understand your point. but this patch doesnt harm, anyway ;-)

We need to understand why a patch is useful before we apply it.

Quoted 5 lines

one annoying problem at the moment is that if we want to compile ACM in, we should modify the value of ACM_USE_SECURITY_POLICY, since the current default value is ACM_NULL_POLICY( which is meaningless as Keir pointed out )

Quoted 7 lines
Quoted 1 line

any clean way to overcome this problem?

The way I skip building acm directory in the root Makefile is quite gross, and won't actually detect if you edit ACM_USE_SECURITY_POLICY. Probably need to think about ways of cleanly expressing a new build config option for security policies etc. Then Makefile decision can hook off of that.

There is one solution: define the value of ACM_USE_SECURITY_POLICY in xen/Makefile, then "make" will put its value into acm code (using sed on a "template" configuration header file, for example)

Is that clean enough? If that is fine, I am ready to send a patch.

regards,
aq

#17 lore raw
In reply to aq

[email protected] wrote on 06/23/2005 11:22:04 AM:

Quoted 6 lines · Keir Fraser
Quoted 5 lines · Stefan Berger
Quoted 3 lines
Quoted 3 lines

ok, i see the point. the problem is because i moved some codes (acm_init() and acm_init_binary_policy()) to acm_hooks.h. now it

seems

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

better to move them back. but it is weird that i got no problem

with

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

gcc 3.3.5

could you please try again with the new patch below?

I tried it with your attached patch. There was an unused function

when

Quoted 10 lines
Quoted 10 lines
Quoted 3 lines

trying out the NULL policy. The attached patch on top of yours and things
compile fine.

I'm still confused what these patches are aiming to fix. If we are building 'NULL' security policy then all the hooks should compile away to nothing and acm core files do not get built. So why do they need patching with ifdef's conditional on whether or not the policy is 'NULL'?

Quoted 3 lines
Quoted 3 lines

Currently, if you re-enable building of acm/ directory in the Xen root Makefile, yet the ACM_USE_SECURITY_POLICY is NULL_POLICY, the build will certainly fail. But I don;t see why we would want to support

that.

Quoted 3 lines
Quoted 1 line

:-)

Keir, certainly i understand your point. but this patch doesnt harm,

anyway ;-)

Quoted 5 lines

one annoying problem at the moment is that if we want to compile ACM in, we should modify the value of ACM_USE_SECURITY_POLICY, since the current default value is ACM_NULL_POLICY( which is meaningless as Keir pointed out )

We have a choice of compiling in a NULL policy on two levels now:

Do not define ACM_USE_SECURITY_POLICY on makefile level to not compile any policy code in the xen/acm directory and effectlively have a NULL policy.

If ACM_USE_SECURITY_POLICY is defined on the makefile level and ACM_NULL_POLICY is the default as the policy to compile (see the choice in xen/include/public/acm.h), we also get a NULL policy. The inline calls that are compiled into the code will all be removed since they default to 'return 0'. - so no hooks there and no overhead.

Is it a problem to have that 2nd level choice of a NULL policy?

Stefan