linux-kernel - Re: RFC: time_namespaces(7) manual page

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:   Tue, 7 Apr 2020 15:06:45 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Andrei Vagin <avagin@...il.com>
Cc:     mtk.manpages@...il.com, Andrei Vagin <avagin@...nvz.org>,
        Dmitry Safonov <dima@...sta.com>,
        linux-man <linux-man@...r.kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Linux API <linux-api@...r.kernel.org>,
        Containers <containers@...ts.linux-foundation.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andy Lutomirski <luto@...nel.org>,
        Adrian Reber <adrian@...as.de>
Subject: Re: RFC: time_namespaces(7) manual page

On 4/7/20 12:30 PM, Thomas Gleixner wrote:
> Andrei Vagin <avagin@...il.com> writes:
>> On Sat, Apr 04, 2020 at 01:08:50PM +0200, Michael Kerrisk (man-pages) wrote:
>>>    /proc/PID/timens_offsets
>>>        Associated  with  each  time namespace are offsets, expressed with
>>>        respect to the initial time namespace, that define the  values  of
>>>        the  monotonic  and  boot clocks in that namespace.  These offsets
>>>        are exposed via the file  /proc/PID/timens_offsets.   Within  this
>>>        file,  the  offsets  are  expressed  as  lines consisting of three
>>>        space-delimited fields:
>>>
>>>            <clock-id> <offset-secs> <offset-nanosecs>
>>>
>>>        The clock-id identifies the clock whose offsets are  being  shown.
>>>        This field is either 1, for CLOCK_MONOTONIC, or 7, for CLOCK_BOOT‐
>>>        TIME.  The remaining  fields  express  the  offset  (seconds  plus
>>>        nanoseconds)  for the clock in this time namespace.  These offsets
>>>        are expressed relative to the clock values  in  the  initial  time
>>>        namespace.   In  the  initial time namespace, the contents of this
>>>        file are as follows:
>>
>> I think we can mention that offset-secs can be negative, but
>> offset-nanosleep has to be 0 or positive.
> 
> I assume you meant offset-nanosecs :)
> 
> That aside, there are also limitations in place.
> 
>   1) Negative offsets which would offset time into negative space are
>      rejected, i.e. its enforced that
> 
>           now(CLOCK) + offset[CLOCK] >= 0
> 
>      This is necessary as the kernel expects and also enforces that time
>      cannot be negative.
> 
>   2) Positive offsets which would offset time above KTTIME_SEC_MAX / 2 are
>      rejected, i.e. it's enforced that
> 
>           now(CLOCK) + offset[CLOCK] <= KTIME_SEC_MAX / 2
> 
>      That is done to prevent that clocks wrap around if the offset would
>      bring it close enough to the wrap around point.
> 
>      The cutoff value is a pretty arbitrary choice (~146 years). So to
>      hit this you'd need a system which has an uptime of > 146 years,
>      which is pretty much unrealistic.

Thanks Thomas!

I've tried to capture this info, as well some other relevant errors
in the following text. Does it look okay?

       Writes  to  the  timens_offsets  file  can fail with the following
       errors:

       EINVAL An offset-nanosecs value is greater than 999,999,999.

       EINVAL A clock-id value is not valid.

       EPERM  The caller does not have the the CAP_SYS_TIME capability.

       ERANGE An offset-secs value is out of range.  In particular;

              · offset-secs can't be set to a value which would make  the
                current time on the corresponding clock inside the names‐
                pace a negative value; and

              · offset-secs can't be set to a value such that the time on
                the corresponding clock inside the namespace would exceed
                half of the value of the  kernel  constant  KTIME_SEC_MAX
                (this  limits  the  clock  value to a maximum of approxi‐
                mately 146 years).

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/