|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] acm
On 09/08/2011 15:34, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote: > On Tue, 2011-08-09 at 15:29 +0100, Konrad Rzeszutek Wilk wrote: >> Tim, George, >> >> Any ideas who at might know more about the ACM flask? > > Didn't Keir remove ACM support back in 23097:2aeebd5cbbad? Probably post > Xen 4.1 but on that basis I wouldn't recommend enabling it on any recent > release which happened to include it -- it was removed because it was > unmaintained. Yes, Flask and ACM are (were) two different security models implemented under a common XSM security framework. Only Flask is being actively maintained, so I deleted ACM. I would recommend Gentoo only enable xsm in their build -- at least if that fails there are maintainers who should be interested in helping to fix it. Noone will help you with acm. -- Keir > Ian. > >> >> On Sat, Aug 06, 2011 at 04:28:37PM +0800, Windows Live wrote: >>> >>> ------- Comment >>> >>> #15 From >>> Konrad Rzeszutek Wilk >>> 2011-08-05 19:11 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> Just copy-n-paste the bug and post it on xen-devel mailing list. >>> >>> >>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1775 >>> >>> a reduced summary; >>> >>> >>> 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 >>> >>> ------- Comment >>> >>> #1 From >>> IAN DELANEY >>> 2011-07-30 02:36 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> 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? >>> >>> >>> >>> >>> ------- Comment >>> >>> #3 From >>> IAN DELANEY >>> 2011-07-30 07:31 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> 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? >>> >>> >>> >>> >>> >>> >>> ------- Comment >>> >>> #6 From >>> Konrad Rzeszutek Wilk >>> 2011-07-30 08:26 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> (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. >>> >>>> >>> >>> >>> >>> >>> >>> >>> ------- Comment >>> >>> #7 From >>> IAN DELANEY >>> 2011-07-30 08:40 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> 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 >>> >>> >>> >>> >>> ------- Comment >>> >>> #8 From >>> IAN DELANEY >>> 2011-07-30 10:04 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> ------- Comment >>> >>> #9 From >>> Konrad Rzeszutek Wilk >>> 2011-07-31 08:14 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> (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. >>>> >>> >>> >>> >>> >>> >>> >>> ------- Comment >>> >>> #10 From >>> IAN DELANEY >>> 2011-07-31 08:49 >>> >>> [reply] >>> ------- >>> >>> >>> >>> >>> 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. >> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@xxxxxxxxxxxxxxxxxxx >>> http://lists.xensource.com/xen-devel >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |