linux-kernel - Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

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]

Message-ID: <1d3d00ac-c7a0-7168-0450-8a0e1499ea2b@redhat.com>
Date:   Wed, 25 Nov 2020 22:05:30 -0500
From:   Carlos O'Donell <carlos@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Zack Weinberg <zackw@...ix.com>, Cyril Hrubis <chrubis@...e.cz>
Cc:     Dmitry Safonov <dima@...sta.com>, Andrei Vagin <avagin@...il.com>,
        GNU C Library <libc-alpha@...rceware.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Petr Špaček <petr.spacek@....cz>
Subject: Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME
 support plans in Linux time namespaces

On 11/25/20 7:17 PM, Thomas Gleixner wrote:
> Carlos, Petr,
> 
> On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
>> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>>> So from my point of view asking for distorted time still _is_ a request
>>> for ponies.
>>
>> I'm happy if you say it's more work than the value it provides.
> 
> Thinking more about it. Would a facility which provides:
> 
>          CLOCK_FAKE_MONOTONIC|BOOTTIME|REALTIME
> 
> where you can go wild on setting time to whatever you want solve
> your problem?

We would need a way to inject CLOCK_FAKE_* in lieu of the real
constants.

There are only two straight forward ways I know how to do that
and they aren't very useful e.g. alternative build, syscall hot-path
debug code to alter the constant.

We might write a syscall interception framework using seccomp
and SECCOMP_RET_TRACE, but that involves ptrace'ing the process
under test, and is equivalent to a micro-sandbox. I'm not against
that idea for testing; we would test what we ship.

I don't think eBPF can modify the incoming arguments.

I need to go check if systemtap can modify incoming arguments;
I've never done that in any script.

In what other ways can we inject the new constants?

-- 
Cheers,
Carlos.