[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180621101846.GA10953@openwall.com>
Date: Thu, 21 Jun 2018 12:18:46 +0200
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Cc: Vasily Averin <vvs@...tuozzo.com>
Subject: Re: Minor problem with kernel 431stab123.1 VZ container networking
Hi,
Wow. It took a while for this to get reported, which indicates how few
people use Owl these days and care to upgrade the kernel for Meltdown.
On Wed, Jun 20, 2018 at 06:10:01PM -1000, cpb wrote:
> Hi, I am seeing a problem with the most recent Owl kernel from inside
> the OpenVZ containers, which are also running Owl. Specifically:
>
> These two things do not work inside i686 containers when the host is
> running kernel-2.6.18-431.el5.028stab123.1.owl1.x86_64:
>
> 1. "ifconfig" inside the containers does not work:
>
> root@...tainer:/ # ifconfig
> SIOCGIFCONF: Bad address
Confirmed.
More specifically, this happens when running the 32-bit ifconfig binary
on 64-bit kernel, regardless of whether containers are used or not. It
doesn't happen for same kernel and userland program bitness (both 64 on
64 and 32 on 32 work fine). Also, in the 32 on 64 case "ifconfig lo",
etc. works fine - only(?) use without an interface name is affected.
Other issues I found is that strace and gdb fail on 32-bit binaries when
running a 64-bit kernel. strace doesn't report any syscalls, gdb
complains that it fails to insert a breakpoint. Again, these issues
don't appear for same bitness of kernel and program being traced.
> 2. Apache 2.2.34 (and 2.2.21) do not start, error_log shows:
>
> [Sat Jun 16 14:40:39 2018] [emerg] (14)Bad address: Couldn't set permissions on cross-process lock; check User and Group directives
This is actually a big deal.
> These things work:
>
> 1. Everything on the host seems to work normally (like ifconfig).
> 2. Inside containers, sshd starts and works OK.
> 3. Inside containers, netstat -nr looks normal.
> 4. Inside containers, dmesg looks normal, no obvious errors.
> 5. When I revert the host kernel, containers go back to normal,
> meaning they works with kernel-2.6.18-419.el5.028stab122.4.owl1.x86_64
>
> This is a minor problem and I am not asking for a solution. I just
> wanted to mention it in case someone recognizes this problem or if there
> are any simple things to try.
You may try booting with the nopti kernel parameter. Then verify that
the line below no longer appears in dmesg:
x86/pti: Kernel page table isolation enabled
> I rebuilt the 431-stab123.1.owl1 kernel
> with CONFIG_KAISER=n, but I must have done this improperly because the
> host hung at boot (I editted dot-config-x86_64, then "make PACKAGE=kernel",
> I know that's not the right way to disable a kernel build-time option,
> but hey, it sure was easy!)
I guess building with CONFIG_KAISER=n was never tested in this backport
of KAISER (certainly not by us, and probably not by Red Hat for RHEL5),
which is why it failed for you. You similarly can't build a RHEL kernel
e.g. without SMP support (luckily, failed for me at build time when I
tried). They expect that core features like this will be always
enabled, like in their shipped configs. Our configs differ quite a bit
from RHEL's, but until we've tried we never know which combinations of
options work and which don't.
> P.S. May I suggest adding libpopt-devel-static in installorder.conf so
> the vztemplates can rebuild themselves without a patch?
Hmm, yes. That package is tiny. We probably broke this with the update
of RPM in Owl-current, which isn't present in 3.1-stable, so that branch
won't need this fix. I've just checked and we do have
libpopt-devel-static installed (manually) in the Owl-current containers
where we build vztemplates.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
