Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Jul 2012 21:13:48 +0400
From: Vasily Kulikov <>
Subject: Re: vzctl 3.3 && CPT


On Thu, Jul 26, 2012 at 15:40 +0400, wrote:
> On 26-Jul-2012 15:04:05 +0400, Vasily Kulikov wrote:
>  > 3) stay at vzctl 3.0.23.
>  > I'm going with (3) now as it doesn't limit our future wishes.
>  > Forwardporting bitness patch will be rather simple, I guess.
> I think the best solution is to stay at (3) while working on (2).

So, I've successfully backported bitness_lock patch to our RHEL6-based
kernel.  The patched vzctl seems to work on both i686 and x86_64
kernels (tested on trivial lock.c sample which I've posted at LKML
thread related to bitness_lock).


1) The kernel patch should not limit bitness_lock functionality even if
we run 32-bit kernel (or 64-bit kernel without IA32_EMULATION support)
because the information about the locked bitness must present in cases
of CT migration.

E.g. if we run 64-bit container on 64-bit system with
CONFIG_IA32_EMULATION=y and a process inside of it locks itself with 64
bits, the lock must be still kept if we migrate it to a 64-bit system with
CONFIG_IA32_EMULATION=n and then migrate it back.

Also, one should be able to lock itself with 32 bits on 32-bit kernel
and then be migrated to 64-bit system.  The task must not be able to do
64-bit syscalls in this case.

FWIW, I haven't tested CPT functionality with bitness_lock, I'm sure it
is not ready for CPT yet.

2) My current vzctl patch is rather ugly.  lock_on_exec locks a task
only at the next execve(), but it disappears if execve(2) fails.  IOW,
execve("/no-such-binary")+execve("/bin/bash") doesn't lock the task.
So, vzctl must re-set this flag before each call to execve().  vzctl
uses deep calls from main() to actual execve(), so it is rather awkward
to explicitly pass "bitness_lock" argument through so many functions
(a structure with all params is not passed, unfortunately).  For now, I
just use a global variable to identify whether a prctl(2) should be
called before execve(2).

I'll try to think more about the way of passing this data (probably
vzctl already uses such global variables for implicit argument passing?).



Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ