Summary: | RPC Protocol Error with xen-tools-3.0.2-r2 and hardened profile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Ross (RETIRED) <aross> |
Component: | Current packages | Assignee: | Gentoo Xen Devs <xen> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | bplant, langthang, luckyluke |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://lists.xensource.com/archives/html/xen-users/2006-07/msg00111.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 144994 |
Description
Andrew Ross (RETIRED)
2006-07-27 02:18:14 UTC
Any idea how this can be fixed in the ebuild? I won't be in a position to test this for a few days, but using "append-flags -fno-stack-protector" should have the same benefit as using gcc's hardened-nossp profile. However, we can't force this in the python ebuild - perhaps pkg_setup can check if python was built with ssp until a real fix can be found. Thanks to solar on IRC for suggesting "scanelf -s __guard -q `which python`" to check if python was built using ssp. Fixed in xen-tools-3.0.2-r3 I have been using hardened profile for a long time without this issue. I really don't like this "workaround" (reemerge python with -fno-stack-protector) . I'll reemerge my system with "-mno-tls-direct-seg-refs" to see if I can reproduce this bug. I also dont like this "workaround". I solved this problem by 'custom-cflags' USE option. My cflags in make.conf: CFLAGS="-pipe -march=prescott -Os -march=prescott -fomit-frame-pointer -frename-registers -fweb -freorder-blocks -mno-tls-direct-seg-refs" USE=custom-cflags works for me as well - thanks, Raimonds. Brad, I take it you're not using custom-cflags? (In reply to comment #7) > USE=custom-cflags works for me as well - thanks, Raimonds. > > Brad, I take it you're not using custom-cflags? > No, I wasn't using the custon-cflags USE flag. I just recompiled python and xen-tools using the hardened compiler and I seem to be able to create domains without any problems. I'm not aware of why this would have started working suddenly. Python was definitely compiled with stack smashing: xen2 ~ # scanelf -s __guard /usr/bin/python TYPE SYM FILE ET_DYN __guard /usr/bin/python And I definitely compiled xen-tools without the custom-cflags USE flag: xen2 ~ # emerge -pv xen-tools These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-emulation/xen-tools-3.0.2-r3 -custom-cflags -debug -doc +hardened +screen +sdl +vnc 0 kB I was able to successfully create guest domains with both xen-tools 3.0.2-r1 (what I was originally using) and with 3.0.2-r3 which I only updated to today. I did however have to comment out the section that checked to see if python was compiled with stack smashing. Cheers, Brad On hardened amd64 xend is also running fine with ssp: xen1 ~ # scanelf -s __guard /usr/bin/python TYPE SYM FILE ET_DYN __guard /usr/bin/python I did some tests today, and just to summarize current status on hardened x86: - the RPC Protocol Error is caused by python being compiled in the 'normal way', eg. with hardened compiler, usual CFLAGS. - recompiling python-2.4.3-r4 with i386-pc-linux-gnu-3.4.6-hardenednossp does solve the problem (no need to use vanilla, nossp is ok) - recompiling xen-tools with other (nossp, vanilla, anything) compilers or CFLAGS does not solve the problem. If python is compiled without ssp, xen-tools will work ok even if compiled with the usual hardened compiler. - don't know about xen-tools-3.0.2-r3 (see <a href="#c4">comment #4</a>), but xen-tools-3.0.2-r4 does have this problem From my make.conf: CFLAGS="-O2 -march=i686 -pipe -mno-tls-direct-seg-refs" USE="userlocales sysfs screen nptl ncurses snmp" Ebuilds used: python-2.4.3-r4 xen-sources-2.6.16.28 xen-tools-3.0.2-r4 xen-3.0.2 Everything compiled with hardened compiler except python, this way the system works fine with hardened gentoo linux domU's (still looking at why Yuan Jue's freebsd domU does not work, but that's another story). Hope this helps. Is there any progress on this problem? Just to confuse things a bit, I have the same problem as described here, but without using hardened. I can report that this problem disappeared using xen-tools-3.0.4_p1, xen-3.0.4_p1 on hardened/amd64 using default (hardened PIE+SSP) x86_64-pc-linux-gnu-3.4.6. Xen 3.0.2 has been dropped from portage and both 3.0.4 and 3.1.0 seem to be working fine on amd64 and x86 hardened. Closing bug, if anyone still hits this problem using >=3.0.4 please re-open. |