[libvirt] [PATCH] virprocess: Extend list of platforms for setns wrapper

Daniel P. Berrange berrange at redhat.com
Mon Sep 15 15:50:23 UTC 2014


On Mon, Sep 15, 2014 at 05:44:17PM +0200, Martin Kletzander wrote:
> On Mon, Sep 15, 2014 at 05:36:16PM +0200, Michal Privoznik wrote:
> >On 15.09.2014 17:32, Martin Kletzander wrote:
> >>On Mon, Sep 15, 2014 at 04:22:18PM +0100, Daniel P. Berrange wrote:
> >>>On Mon, Sep 15, 2014 at 05:20:46PM +0200, Michal Privoznik wrote:
> >>>>On 15.09.2014 17:15, Martin Kletzander wrote:
> >>>>>On Mon, Sep 15, 2014 at 03:43:55PM +0200, Michal Privoznik wrote:
> >>>>>>Currently, the setns() wrapper is supported only for x86_64 and i686
> >>>>>>which leaves us failing to build on other platforms like arm, aarch64
> >>>>>>and so on. This means, that the wrapper needs to be extended to those
> >>>>>>platforms and make to fail on runtime not compile time.
> >>>>>>
> >>>>>>The syscall numbers for other platforms was fetched using this
> >>>>>>command:
> >>>>>>
> >>>>>>kernel.git $ git grep "define.*__NR_setns" | grep -e arm -e powerpc -e
> >>>>>>s390
> >>>>>>arch/arm/include/uapi/asm/unistd.h:#define
> >>>>>>__NR_setns                   (__NR_SYSCALL_BASE+375)
> >>>>>>arch/arm64/include/asm/unistd32.h:#define __NR_setns 375
> >>>>>>arch/powerpc/include/uapi/asm/unistd.h:#define
> >>>>>>__NR_setns               350
> >>>>>>arch/s390/include/uapi/asm/unistd.h:#define __NR_setns          339
> >>>>>>
> >>>>>>Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> >>>>>>---
> >>>>>>src/util/virprocess.c | 18 ++++++++++++------
> >>>>>>1 file changed, 12 insertions(+), 6 deletions(-)
> >>>>>>
> >>>>>
> >>>>>NACK, we shouldn't be duplicating syscall definitions.  There should
> >>>>>be AC_CHECK_FUNCS([setns]) (instead of AC_CHECK_FUNCS_ONCE() for the
> >>>>>syscall) and having with_lxc = "yes" and ac_cv_func_setns != "yes"
> >>>>>should result in an error.
> >>>>
> >>>>The only problem with this might be that on systems with older glibc
> >>>>(and
> >>>>there is plenty of them) libvirt will fail to build / miss this
> >>>>feature. And
> >>>>it's not that the kernel doesn't support the namesapces. But let me
> >>>>see if I
> >>>>can get some ACKs on that approach you're suggesting.
> >>>
> >>>That's basically what the code did before we added the #define or
> >>>NR_setns.
> >>>We took the patch specifically to help Debian where the kernel has it but
> >>>glibc is outdated.
> >>>
> >>
> >>Either Debian should patch their glibc or we should at lease use
> >>SYS_setns IMHO.
> >
> >That's not gonna fly either. On my system, the SYS_setns is declared in:
> >
> ># grep -r SYS_setns /usr/include/
> >/usr/include/bits/syscall.h:#define SYS_setns __NR_setns
> >
> >And the syscall.h belongs to glibc, not kernel headers. So we are back
> >at the start.
> >
> 
> Well, I'd argue that we're not :)  Distros could make our lives easier
> by not requiring us to guess their kernel's syscall numbers :)

Well we're not guessing - syscalls numbers are standardized ABI that does
not change per distro. Realistically rebasing glibc in existing distros
to pull in new functions isn't something distros are going todo. So unless
we do a workaround in libvirt, users on that distro are facing a regression
due us switching a bunch of LXC APIs to use setns() for a previous security
fix.  So I think defining  NR_setns in libvirt code is the least bad, from
many unpleasant options.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list