[gentoo-hardened] Problems compiling xen - please help...

[gentoo-hardened] Problems compiling xen - please help...

[Ed W]

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...


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
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ned Ludd]

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ed W]

>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.
>  
>

Hi Ned,

thanks for the quick reply. You are loosing me a little here.

The package I am compiling is the Xen userland tools, ie package 
"app-emulation/xen-3.0.0-r2".

I have tried changing compilers eg:

gcc-config i686-pc-linux-gnu-3.4.4-vanilla && source /etc/update
emerge -vp xen

This still raises the same error.

I'm going to have a peek at the udev package, but could you please 
expand on what you mean by your other workaround suggestion please?  Can 
anyone else confirm that they CAN compile this package on hardened?

Thanks for your help

Ed W
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ed W]

Hi

> I'm going to have a peek at the udev package, but could you please 
> expand on what you mean by your other workaround suggestion please?  
> Can anyone else confirm that they CAN compile this package on hardened?


I can't see that udev is doing anything special to work around hardened 
compiler issues?  Can anyone please help me debug this problem?

Cheers

Ed W
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

On Thu, 02 Feb 2006 15:03:53 +0000
Ed W <lists@wildgooses.com> 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:

File a bug.  These unresolved symbols indicate those files have been
compiled with the stack protector on, as can be seen from the
compilation lines. However while the ebuild does do the 'filter-flags
-fPIE -fstack-protector' the build is ignoring CFLAGS for some of its
compilations.

An alternative for now, is to switch to the -hardenednopiessp variant
of your compiler and build it with that.

> 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...
> 
> 
> 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


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ed W]

Hi,

>An alternative for now, is to switch to the -hardenednopiessp variant
>of your compiler and build it with that.
>  
>

Thanks for everyones responses, but this is what I already tried!!!

When I switch compiler using gcc-config (see previous email for example 
command line) then there NO DIFFERENCE in compiled output!?!

Does this suggest that something screwy is happening and it's not really 
changing the compiler in the way I expect?  "gcc -v" is changing though...

Very peculiar

I appreciate any suggestions here please...?

Cheers

Ed W
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ed W]

> Thanks for everyones responses, but this is what I already tried!!!
>
> When I switch compiler using gcc-config (see previous email for 
> example command line) then there NO DIFFERENCE in compiled output!?!
>
> Does this suggest that something screwy is happening and it's not 
> really changing the compiler in the way I expect?  "gcc -v" is 
> changing though...



Whoooa.  Hold that thought.  On a sudden realisation I tried blowing 
away the ccache directory and switched to hardened_nopiessp and it then 
built correctly... Very strange. 

I was under the mistaken believe that ccache could detect when the 
compiler was switched and would not re-use it's old cache files.  
Certainly it was taking different amounts of time to compile when I 
changed compiler versus re-running under the orig compiler config.  
Obviously the cache algorithm is not perfect though.

Heads up then that when switching compiler to the non-hardened one it 
makes sense to blow away the ccache of disable it's use.


Thanks for everyones responses

Ed W
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ned Ludd]

On Thu, 2006-02-02 at 17:59 +0000, Ed W wrote:
> > Thanks for everyones responses, but this is what I already tried!!!
> >
> > When I switch compiler using gcc-config (see previous email for 
> > example command line) then there NO DIFFERENCE in compiled output!?!
> >
> > Does this suggest that something screwy is happening and it's not 
> > really changing the compiler in the way I expect?  "gcc -v" is 
> > changing though...
> 
> 
> 
> Whoooa.  Hold that thought.  On a sudden realisation I tried blowing 
> away the ccache directory and switched to hardened_nopiessp and it then 
> built correctly... Very strange. 
> 
> I was under the mistaken believe that ccache could detect when the 
> compiler was switched and would not re-use it's old cache files.  
> Certainly it was taking different amounts of time to compile when I 
> changed compiler versus re-running under the orig compiler config.  
> Obviously the cache algorithm is not perfect though.
> 
> Heads up then that when switching compiler to the non-hardened one it 
> makes sense to blow away the ccache of disable it's use.

That probably makes sense for any time a gcc-config switch happens. You 
should probably file a bug about that for the maintainer of gcc-config.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Thu, 02 Feb 2006 13:18:46 -0500
Ned Ludd <solar@gentoo.org> wrote:

> On Thu, 2006-02-02 at 17:59 +0000, Ed W wrote:
> > Heads up then that when switching compiler to the non-hardened one
> > it makes sense to blow away the ccache of disable it's use.
> 
> That probably makes sense for any time a gcc-config switch happens.
> You should probably file a bug about that for the maintainer of
> gcc-config.

ccache doesn't take account of anything other than the built-in specs
files and stuff specified via --specs - we could just patch
ccache to pay attention to GCC_SPECS as well.  I'll take a look.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-hardened] Problems compiling xen - please help...

[Ned Ludd]

On Thu, 2006-02-02 at 20:35 +0100, Kevin F. Quinn (Gentoo) wrote:
> On Thu, 02 Feb 2006 13:18:46 -0500
> Ned Ludd <solar@gentoo.org> wrote:
> 
> > On Thu, 2006-02-02 at 17:59 +0000, Ed W wrote:
> > > Heads up then that when switching compiler to the non-hardened one
> > > it makes sense to blow away the ccache of disable it's use.
> > 
> > That probably makes sense for any time a gcc-config switch happens.
> > You should probably file a bug about that for the maintainer of
> > gcc-config.
> 
> ccache doesn't take account of anything other than the built-in specs
> files and stuff specified via --specs - we could just patch
> ccache to pay attention to GCC_SPECS as well.  I'll take a look.

Ok cool but keep in mind.

USE=-hardened emerge gcc
gcc-config 1
echo $GCC_SPECS

USE=hardened emerge gcc
gcc-config 1
echo $GCC_SPECS

Both times it shall be "" with the same version of gcc.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Thu, 02 Feb 2006 15:35:33 -0500
Ned Ludd <solar@gentoo.org> wrote:

> On Thu, 2006-02-02 at 20:35 +0100, Kevin F. Quinn (Gentoo) wrote:
> > On Thu, 02 Feb 2006 13:18:46 -0500
> > Ned Ludd <solar@gentoo.org> wrote:
> > 
> > > On Thu, 2006-02-02 at 17:59 +0000, Ed W wrote:
> > > > Heads up then that when switching compiler to the non-hardened
> > > > one it makes sense to blow away the ccache of disable it's use.
> > > 
> > > That probably makes sense for any time a gcc-config switch
> > > happens. You should probably file a bug about that for the
> > > maintainer of gcc-config.
> > 
> > ccache doesn't take account of anything other than the built-in
> > specs files and stuff specified via --specs - we could just patch
> > ccache to pay attention to GCC_SPECS as well.  I'll take a look.
> 
> Ok cool but keep in mind.
> 
> USE=-hardened emerge gcc
> gcc-config 1
> echo $GCC_SPECS
> 
> USE=hardened emerge gcc
> gcc-config 1
> echo $GCC_SPECS
> 
> Both times it shall be "" with the same version of gcc.

The hash does include the size & mtime of the compiler driver -
although that'll be the wrapper in most cases, I guess, which may not
be good enough.

bug #121336 btw

actually I think hashing the files in GCC_SPECS won't work, as ccache
doesn't see GCC_SPECS because it's set by the compiler wrapper.

I think it may be enough to hash in the output of '<compiler> -v'...
-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-hardened] Problems compiling xen - please help...

[Peter S. Mazinger]

On Thu, 2 Feb 2006, 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:

the CFLAGS miss (at least) -DKERNEL
> 
> 
> 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...
> 
> 
> 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
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Problems compiling xen - please help...

[Peter S. Mazinger]

On Thu, 2 Feb 2006, Ed W wrote:

> 
> >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.
> >  
> >
> 
> Hi Ned,
> 
> thanks for the quick reply. You are loosing me a little here.
> 
> The package I am compiling is the Xen userland tools, ie package 
> "app-emulation/xen-3.0.0-r2".
> 
> I have tried changing compilers eg:
> 
> gcc-config i686-pc-linux-gnu-3.4.4-vanilla && source /etc/update
> emerge -vp xen

if that is userspace stuff (no kernel module) forget what I said about 
-DKERNEL (typo, should have been __KERNEL__) and do source /etc/profile 
after switching your gcc profile

Peter 
> This still raises the same error.
> 
> I'm going to have a peek at the udev package, but could you please 
> expand on what you mean by your other workaround suggestion please?  Can 
> anyone else confirm that they CAN compile this package on hardened?
> 
> Thanks for your help
> 
> Ed W
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-hardened@gentoo.org mailing list