On Thu, 2006-02-02 at 15:03 +0000, Ed W wrote: > I am trying to get Xen running under a hardened kernel. The machine is > currently booted with "selinux=1 enforcing=0". I am having trouble > compiling: > > > gcc -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 -I. -I../../../tools/libxc > -Wall -fno-builtin -O2 -msoft-float -m32 -march=i686 -D__ASSEMBLY__ > -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 -c trap.S > gcc -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 -I. -I../../../tools/libxc > -Wall -fno-builtin -O2 -msoft-float -m32 -march=i686 -c vm86.c > gcc -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 -I. -I../../../tools/libxc > -Wall -fno-builtin -O2 -msoft-float -m32 -march=i686 -c setup.c > gcc -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 -I. -I../../../tools/libxc > -Wall -fno-builtin -O2 -msoft-float -m32 -march=i686 -c util.c > cpp -P -DDEBUG -D_ACPI_ -DTEXTADDR=0x000D0000 vmxassist.ld > vmxassist.tmp > ld -o vmxassist -m elf_i386 -nostdlib --fatal-warnings -N -T > vmxassist.tmp head.o trap.o vm86.o setup.o util.o > vm86.o: In function `address': > vm86.c:(.text+0x19): undefined reference to `__guard' > vm86.c:(.text+0x56): undefined reference to `__stack_smash_handler' > vm86.o: In function `trace': > vm86.c:(.text+0xe9): undefined reference to `__guard' > vm86.c:(.text+0x141): undefined reference to `__guard' > vm86.c:(.text+0x15d): undefined reference to `__stack_smash_handler' > vm86.o: In function `getreg': > vm86.c:(.text+0x278): undefined reference to `__guard' > vm86.o: In function `.L23': > ...etc...
That points at a faultly build system. Normally __guard & __stack_smash_handler are symbols provided to userland. For kernels the hardened specs have a rule to not add ssp. It uses !D__KERNEL__ and or uses the --nostdlib rules. Chances are it needs to use -nostdlib for all the object code it creates. Now if your just lazy and dont want to fix xen itself then just switch over to a set of set of vanilla specs. Compile whatever then switch back. if that fails then include some ssp stubs to it. Same way that's done in udev. > I have tried various combinations of compiler using gcc-config. Neither > gcc-3.4.4 or gcc-3.3.6 seem to do any better, hardened or not > > I suspect that this could be a problem with the compiler still using > some hardend profile despite me asking for a non-hardened gcc? Can > anyone please help debug this > > Ed W -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [email protected] mailing list
