[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120728171348.GA4864@albatros>
Date: Sat, 28 Jul 2012 21:13:48 +0400
From: Vasily Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: vzctl 3.3 && CPT
Hi,
On Thu, Jul 26, 2012 at 15:40 +0400, gremlin@...mlin.ru 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).
However:
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?).
Thanks,
--
Vasily
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.
