This is an archived copy of the Xen.org mailing list, which we have
preserved to ensure that existing links to archives are not broken.
The live archive, which contains the latest emails, can be found at
http://lists.xen.org/
This fault renders xen unworkable, only in the packaged install of distro
gentoo/
gentoo64 grub # eix xen
[I] app-emulation/xen
Available versions: 3.4.2-r1!t (~)4.1.0!t **9999!t {acm custom-cflags
debug flask pae xsm}
Installed versions: 4.1.0!t(00:13:36 07/30/11)(acm debug flask pae xsm
-custom-cflags)
Homepage: http://xen.org/
Description: The Xen virtual machine monitor
This make /boot/xen-4.1.0.gz. On booting into this installed hypervisor, I can
bring up virt-manager which happily lists the vms.
On attempting to boot a v the moment the xen equipped kernel attempts to boot
the vm, the system is crashed.
That is, it seems to trigger reboot because that is what happens,
Just reboot.
I haven't bothered with any logs because this instantaneous crash should fail
to write any events to logs, correct me if I'm wrong
should have mentioned.
idella@gentoo64 ~/bin $ ls /boot/
...........
xen-4.1.0-rc7-pre.gz
xen-4.1.0.gz
........
The xen-4.1.0-rc7-pre.gz is fine
The xen-4.1.0.gz hypervisor is broken.
idella@gentoo64 ~/bin $ emerge xen -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-emulation/xen-4.1.0 USE="acm custom-cflags* debug flask
pae xsm" 0 kB
shows the compiled in features. What can trigger this type of system crash?
It seems the cause of this is in gentoo terms the use of the use flags acm and
xsm. See https://bugs.gentoo.org/show_bug.cgi?id=361345.
It seems disabling these flags allows the hypervisor to boot vms.
What I need to know is where this flaw comes from. There is a gentoo package
xsm, but not asm.
asm is a security portion of the source.
Is the flaw in the gentoo package xsm, is it the xensource code, and can you
list the step or steps to sensure xsm and acm directly in the xensource code so
I can replicate it; suspect they are options manually put after make on the
command line.
------- Comment #5 From IAN DELANEY 2011-07-30 08:01 [reply] -------
Aha
from Config.mk
# Enable XSM security module. Enabling XSM requires selection of an
# XSM security module (FLASK_ENABLE or ACM_SECURITY).
XSM_ENABLE ?= n
FLASK_ENABLE ?= n
ACM_SECURITY ?= n
These are the default settings, so it seems the hypervisor I am using does in
fact not have these set.
So why are they turned off, and do they have an unresolved issue?
(In reply to comment #5)
> Aha
>
> from Config.mk
>
> # Enable XSM security module. Enabling XSM requires selection of an
> # XSM security module (FLASK_ENABLE or ACM_SECURITY).
> XSM_ENABLE ?= n
> FLASK_ENABLE ?= n
> ACM_SECURITY ?= n
>
> These are the default settings, so it seems the hypervisor I am using does in
> fact not have these set.
> So why are they turned off, and do they have an unresolved issue?
B/c the maintainer for them is .. gone? I suspect the code is bit-rotten. You
might want to open a Gentoo bug to turn those off until somebody fixes whatever
the issue you have with ACM.
>
Konrad;
I can get the use flags withdrawn, but the task at hand is to get them to work.
I can say that change to setting
FLASK_ENABLE ?= y
cause the emerge or build to fail in my gentoo
ok I'm picking up the threads.
# make clean
# nano Config.mk
# emerge install-xen
for each alteration.
the build fails only for setting ACM_SECURITY ?= y.
(In reply to comment #7)
> Konrad;
>
> thanks. When you say maintainer, do you mean a gentoo maintainer?
Cool. So in regards to disable ACM/FLask - that was to you. In regards to
actually figuring why ACM/Flask does not seem to work - that was meant for the
maintainer of that code in Xen - who seemed to have moved on to other things.
> I can get the use flags withdrawn, but the task at hand is to get them to work.
Ah, then you will need to figure out why FLASK does not work - I have no
knowledge of that code so won't be much help. You might have better luck
digging up the authors of said code and emailing them.
> I can say that change to setting
> FLASK_ENABLE ?= y
> cause the emerge or build to fail in my gentoo
>
> Thanks for your important help.
>
ok; to correct last entries.
It seems that flask is fine. On repeating it a number of times, for whatever
reason, on compiling the xensource package xen-4.1-testing.hg, it appears that
entries flask and acm will in fact compile fine. It seems that setting flask on
its own will fail, it depends upon xsm being set. Setting xsm om its own or
with flask works.
In fact, setting all 3, the package builds. But like the gentoo emerge, the
hypervisor breaks the system if ACM_SECURITY is set. Setting use=ACM
presumably leads to setting ACM_SECURITY ?= n in the Config.mk. simple. So the
flaw isn't in gentoo, it' in the source.