linux-kernel - Re: per-chroot clock module ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 28 Nov 2010 00:51:25 +0100
From:	Andre Tomt <andre@...t.net>
To:	jason.vas.dias@...il.com
CC:	Ben Gamari <bgamari@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: per-chroot clock module ?

On 11/27/2010 08:22 PM, Jason Vas Dias wrote:
> RE: why ?
> This would allow one to very easily support websites for totally different timezones , where offsets need not be
> restricted to legal timezone offsets but could encompass years - also nice if you want to run applications whose
> license key has expired .  Also very easy to support multiple instances of cron(1) running in different timezones.
> In any case, the module would ensure that the time the kernel sees internally for all processes is the actual real-time
> clock value; only processes which have their root directory in one of the special chroot directories would get
> a different gettimeofday() or clock_gettime() value .
>
>>
>> It seems like what you want here is simple virtualization. Have you
>> considered KVM? The closest thing to your request currently upstream is
>> containers, although I'm unsure of whether a container can be created
>> with an independent clock. Might be something to look into.
>>
>
> To me, using virtualization to solve this problem is like using a sledgehammer to crack a nut,
> particularly if the optimal performance of the processes running in such chroot environments
> is of paramount importance.

You might want to take a look at Linux-Vserver; it has containers (that 
is, chroot on stereoids) with support for "virtualized time"/clock offset.

Virtualized time is not without downsides, it adds overhead. It will be 
tiny compared to using a sledgehammer of course. The vserver guys puts 
it this way;
"This enables per guest time offsets to allow for adjusting the system 
clock individually per guest. this adds some overhead to the time 
functions and therefore should not be enabled without good reason."

http://linux-vserver.org/

It could be useful to implement such a thing in a "time" namespace, 
making it available to lxc containers and cgroups also.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/