linux-kernel - Re: [PATCHv7 01/33] ns: Introduce Time Namespace

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: <alpine.DEB.2.21.1910171039500.1824@nanos.tec.linutronix.de>
Date:   Thu, 17 Oct 2019 11:20:56 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andrei Vagin <avagin@...il.com>
cc:     Vincenzo Frascino <vincenzo.frascino@....com>,
        Dmitry Safonov <dima@...sta.com>, linux-kernel@...r.kernel.org,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrei Vagin <avagin@...nvz.org>,
        Adrian Reber <adrian@...as.de>,
        Andy Lutomirski <luto@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Jann Horn <jannh@...gle.com>, Jeff Dike <jdike@...toit.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Shuah Khan <shuah@...nel.org>,
        containers@...ts.linux-foundation.org, criu@...nvz.org,
        linux-api@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCHv7 01/33] ns: Introduce Time Namespace

Andrei!

On Wed, 16 Oct 2019, Andrei Vagin wrote:
> On Wed, Oct 16, 2019 at 12:39:11PM +0200, Thomas Gleixner wrote:
> > Nah.
> > 
> > config TIME_NS
> > 	bool "TIME namespace"
> > 	depends on GENERIC_VDSO_TIME_NS
> 
> I was thinking to fix this by the same way with a small difference.
> 
> If GENERIC_GETTIMEOFDAY isn't set, it should be safe to allow enabling
> TIME_NS. In this case, clock_gettime works via system call and we don't
> have arch-specific code in this case. Does this sound reasonable?
> 
>         depends on (!GENERIC_GETTIMEOFDAY || GENERIC_VDSO_TIME_NS)

No, that's wrong. If GENERIC_GETTIMEOFDAY is not set, then the architecture
still might have its own VDSO implementation and we agreed in Vancouver a
year ago that we are not going to support per architecture time namespace
VDSO implementations.

So if at all then you want:

   depends on HAVE_GENERIC_VDSO && (!GENERIC_GETTIMEOFDAY || GENERIC_VDSO_TIME_NS)

But that's crap, really.

The reason why HAVE_GENERIC_VDSO and GENERIC_GETTIMEOFDAY exist as separate
config items is not a functional issue. It's there to ease the migration to
the generic VDSO implementation. Having generic VDSO in production without
implementing GENERIC_GETTIMEOFDAY does not make any sense at all.

The architectures which implement VDSO are:

    arm, arm64, mips, nds32, powerpc, riscv, s390, sparc, x86, um

arm64, mips, x86 use the generic VDSO. Patches for arm are floating
around. UM is special as it just traps into the syscalls. No idea about the
rest. Vincenzo might know.

The bad news is that we have no information (except on arm which has a
config switch for VDSO) whether an architecture provides VDSO support or
not.

So unless you add something like

   config HAS_VDSO
   	  bool

which is selected by all architectures which provide VDSO support, the only
sane solution is to depend on GENERIC_VDSO_TIME_NS.

TBH, I would not even bother. The architectures which matter and are going
to use time namespaces already support VDSO and they need to move to the
generic implementation anyway as we discussed and agreed on in Vancouver.

Providing time name spaces for the non VDSO archs is a purely academic
exercise.

Thanks,

	tglx