Subject: Re: [vserver] Any chance of an update to the hardened patch?
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 7 Jul 2009 16:09:07 +0200

On Mon, Jul 06, 2009 at 11:51:39PM +0100, Ed W wrote:
> Hi

> >>- hostname is no longer virtualised - whichever vserver is booted
> >>last sets the hostname for the host and all vservers

> >Too old utils, upgrade to util-vserver-0.30.216+.

> Upgraded to 0.30.216_pre2841, but now it segfaults when I try to start
> a vserver... (actually when I do nearly anything)

any messages in dmesg maybe?

> Note, I now switched to using a non hardened kernel also.  I have 
> 2.6.29.5 with matching VS patch (on intel core2 hardware with 64bit 
> kernel).  Toolchain is still gcc3.4 hardened though (gentoo)

hmm, so an older gcc, but with 'gentoo hardened'
patches? or was that a typo?

> eg
> 
>    #vserver dnsmasq start
>    ..snip..
>    * Starting
>    vixie-cron...                                                            
>    [ ok ]
>    * Starting local...
>    /usr/sbin/chbind: line 135: 14948 Segmentation fault     
>    "${create_cmd[@]}" "${chain_cmd[@]}" -- "$@"
> 
>    ...snip...
>    Failed to start vserver 'dnsmasq'
>    Segmentation fault

> and using the /etc/init.d/vservers.default script under gentoo I get:
> 
>    /etc/init.d/vservers.default restart
>    * Caching service
>    dependencies...                                                          
>    [ ok ]
>    * Stopping vservers of type
>    'default'...                                                             
>    [ ok ]
>    * Starting vservers of type 'default'...
>    /bin/sh: line 1: 12477 Segmentation fault      /usr/sbin/vserver
>    --defaulttty --sync "dnsmasq" start
>    make: *** [.dnsmasq.stamp] Error 139
>    /bin/sh: line 1: 12487 Segmentation fault      /usr/sbin/vserver
>    --defaulttty --sync "fs" start
>    make: *** [.fs.stamp] Error 139

> Switched back to 0.30.215 for the time being

> >>- "vserver xyz enter" frequently segfaults - using util-vserver 0.30.215

> >Got core dumps or similar?

> I'm struggling to get a useful one. In gdb I just see some hints it 
> might be from `login, so I assumed it meant /bin/login and rebuilt both 
> util-vserver and shadow with debug symbols.  Because I run hardened I 
> also also set LDFLAGS="-nopie".

what does `vserver-info - SYSINFO` give?

> Then I run it up in gdb and ask it for a backtrace against /bin/login, 
> but just get

> gdb /bin/login --core /vservers/images/www2/core
> ...snip...
> warning: core file may not match specified executable file.
> Core was generated by 
> `login                                                                      
> '.
> Program terminated with signal 11, Segmentation fault.
> [New process 26874]
> #0  0x00000000004014b8 in ?? ()
> (gdb) thread apply all bt full

> Thread 1 (process 26874):
> #0  0x00000000004014b8 in ?? ()
> No symbol table info available.
> #1  0x0f0000000fc0c748 in ?? ()
> No symbol table info available.
> #2  0x0000000000000000 in ?? ()
> No symbol table info available.

> How can I check which app it's actually a coredump for?  How can I test 
> I have proper debug symbols on that app?

objdump -s -j note0 core.dump

should give some clues ...

HTH,
Herbert

> >Try showattr. Note that with recent utils and a recent kernel, you don't
> >actually need the barrier anymore.

> Aha, showattr is giving me the answer I expected.  Super
> 
> Thanks for any thoughts on the problems above?
> 
> Ed W
> 
>