Subject: Re: [vserver] Any chance of an update to the hardened patch?
From: Ed W <lists@wildgooses.com>
Date: Mon, 06 Jul 2009 23:51:39 +0100
Mon, 06 Jul 2009 23:51:39 +0100
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)

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)


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

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?

> 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




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)

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)


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

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?

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